এই প্রকল্পটির উত্তর কেবলমাত্র আপনার প্রকল্পের নেতৃত্ব দ্বারা দেওয়া যেতে পারে, বা যে কেউ "টিকিট প্রক্রিয়া" এর দায়িত্বে রয়েছে।
তবে আমাকে অন্য উপায়ে জিজ্ঞাসা করতে দিন: আপনি যে প্যাগটি ফেলেছেন তা আপনি রেকর্ড করবেন না কেন ?
আমি দেখতে পেলাম একমাত্র দুর্গন্ধযুক্ত কারণ হ'ল বাগ প্রতিবেদন দাখিল করার প্রচেষ্টা, এর বিরুদ্ধে প্রতিশ্রুতিবদ্ধকরণ এবং এটি বন্ধ করার চেষ্টাটি বাগের সংশোধন করার সময়ের চেয়ে বড় আকারের আদেশ।
এই ক্ষেত্রে, সমস্যাটি ঠিক নয় যে বাগটি এত সহজে সমাধান করা যায়, তবে কাগজপত্রটি খুব বেশি সময় নেয়। এটা আসলে করা উচিত নয়। আমার জন্য, জিরা টিকিট তৈরি করার জন্য ওভারহেড টিপছে c
, তারপরে একটি সংক্ষিপ্ত 1-লাইন সংক্ষিপ্তসার প্রবেশ করিয়ে টিপছে Enter
। বর্ণনাটি ওভারহেডের মতো নয়, কারণ আমি ইস্যু নম্বর সহ একসাথে প্রতিশ্রুতি বার্তায় এটিকে কেটে পেস্ট করতে পারি। শেষে, . c <Enter>
এবং সমস্যাটি বন্ধ। ওপরে 5 টি টিপতে টিপুন।
আমি আপনার সম্পর্কে জানি না, তবে প্রতিটি বাগফিক্সকে এভাবে রেকর্ড করার জন্য এমনকি ছোট ছোট প্রকল্পগুলিতেও এটি একটি নীতি তৈরি করার পক্ষে যথেষ্ট ।
সুবিধাটি সুস্পষ্ট - বেশ কয়েকটি লোক খুব সহজেই জিরার মতো টিকিট ব্যবস্থা নিয়ে কাজ করতে পারে তবে সোর্স কোড দিয়ে নয়; টিকিট সিস্টেম থেকে উত্পন্ন উত্সগুলিও রয়েছে, তবে উত্স থেকে নয়। আপনি এখানে অবশ্যই আপনার বাগ সংশোধন করতে চান, সম্ভাব্য উন্নয়নগুলি সম্পর্কে জানতে, ছোট 1-লাইন বাগফিক্সের ক্রমাগত বর্ধমান প্রবাহের মতো, যা আপনাকে প্রক্রিয়া সমস্যা বা যা-ই হোক না কেন কিছুটা অন্তর্দৃষ্টি সরবরাহ করতে পারে। উদাহরণস্বরূপ, আপনাকে প্রায়শই কেন এই জাতীয় ছোট বাগ সংশোধন করতে হয় (ধরে নেওয়া যায় যে এটি প্রায়শই ঘটে থাকে)? এটা কি হতে পারে যে আপনার পরীক্ষাগুলি যথেষ্ট ভাল না? বাগফিক্সটি একটি ডোমেন পরিবর্তন, বা একটি কোড ত্রুটি ছিল? প্রভৃতি