Permalink to this article – https://ift.tt/0gkIBAC
Software eats the world, open source eats software! The issue-driven development model based on the issue tracking system not only has an important impact on the development process of open source systems, but in the field of commercial software development, more and more companies and organizations are also using the issue-driven development method. .
For the issue (work order) mentioned here, we can’t just interpret it as a bug as in the past, which is too narrow and outdated. Today’s issues carry information that is “all-encompassing”. Everything related to project/repo is put forward in the form of issues, including new features, bugs, improvements, technical proposals, tasks, discussions, and more.
With the issue tracking system, we will face a problem, that is, how to organize issues to make the issue-driven software development process more scientific and efficient? To this end, I read several papers on the Empirical study (empirical research) on issue organization and management (see the “References” section for the reading address), and here is a summary of the paper’s conclusions:
- Use labels to facilitate problem solving in software projects;
- Projects that use the multiple label feature can manage their issues more efficiently.
Has the keyword get arrived? Yes, it is “multi-label”. Using multiple labels to organize issues can be more effective in managing issues. So which tags to set, and how to label multiple issues? Regarding these questions, the paper does not give answers, and we still need to practice and explore on our own.
In this article, I will give an idea of issue-driven software development practice based on multiple labels for your reference, but note : this is not the best practice, it is just a feasible (even immature) practice. , readers can also expand on the basis of this practice.
1. Label management, classification first
Schematic diagram of Go project using multi-label organization issue
Most issue tracking systems have a built-in set of labels for you to choose and use directly. For example, the following are the default issue labels provided by github and gitlab:
- github’s default issue label collection
- bug - enhancement - document - duplicate - good first issue - help wanted - invalid - question - wontfix
- gitlab’s default issue label collection
- bug - enhancement - documentation - suggestion - discussion - support - confirmed - critical
At the same time, the issue tracking system also supports custom labels, but we cannot define new labels mindlessly . We must consider the function of labels and classify them scientifically.
Let’s analyze the default labels provided by github and gitlab above. Most of them are used to represent the category of issue. Therefore, we must first define a set of labels that can represent the issue category . This can be combined with the above default label set and combined with daily work. Context needs to be customized.
For example, I have customized the following set of labels representing issue categories:
- bug - feature - task - proposal - enhancement - suggestion - discussion
These labels are the basis of the entire issue-driven development. Each newly created issue must first be assigned a label representing the category. Following the principle that the most commonly used labels should be as short as possible, we use a single word to represent For each label , no prefix string is used.
Next, let’s define several groups of label sets:
- A collection of labels representing workflows
- workflow/confirmed - workflow/accepted - workflow/need-investigation - workflow/wait-for-info - workflow/need-proposal - workflow/need-review - workflow/declined - workflow/blocked - workflow/wontfix - workflow/duplicate
The reason why the workflow prefix is used is to reduce the burden on developers to consider what kind of collection the label is when choosing a label, and the prefix is clear at a glance.
- A set of labels representing priority
- priority/critical - priority/release-blocker - priority/security - priority/urgent
- Represents a collection of labels involving components
- component/proto - component/tracing - component/logging - component/metrics - component/api ... ...
When defining label sets for different functions, be sure to pay attention to the following points:
- Generally, there is no need to customize labels such as todo
Which new issue put into the issue system does not need todo, and then defining a todo label is a bit superfluous. In addition, many code warehouse management tools with built-in kanban function will automatically include your newly created issue in the todo column of the milestone kanban after the issue is included in a milestone.
- The version information of the issue can be calibrated with milestone
We generally do not need to create a label that holds version information, we can use milestone (milestone) to identify the version attribute of the issue.
- Define the label set from top to bottom
For the same organization, the consistency of the workflow is very important, so we need to define the label set from top to bottom, instead of each project defining its own label set.
If you are using gitlab (according to the survey, most domestic companies use gitlab), since the group in gitlab supports label definition, we can define a set of labels in the top-level group, so that the subgroup and project repo below it can be “Inherit” this set of labels.
If the project has personalized label requirements, the project can customize its own label on the basis of the unified label set, which will avoid a lot of repeated definitions, maintain the consistency of the label set, and lay the foundation for subsequent workflow operations.
After defining these types of issues, let’s take a look at the process of the issue from creation to driving development “running”.
2. Workflow driven by multiple label issues
Schematic diagram of multi-label issue-driven workflow
1) Planning and creating milestones
No matter which development process (waterfall, iterative or agile) is adopted, the final output is to output the results. We usually output the results of each version as a milestone, so before creating an issue, we will first plan and create a milestone, The milestone itself also contains the version attribute of the issue .
If you are using gitlab, you can set milestones either at the group level or on a specific project.
If your output is a product with multiple services, setting milestones at the group/subgroup level can unify the release version of the product.
In addition, we can create a long-term milestone of backlog at the appropriate level to collect issues that have not yet been assigned a version.
Once the milestone is planned and created in this way, the leader can manage the milestone later. Next we can create an issue.
2) Create an issue and select category label
Our workflow requirements: Whenever a developer, tester, leader or related person creates an issue, be sure to select a category label .
- bug：导致产品或服务未按预期工作的问题- feature：新增的功能特性或非功能特性- enhancement：已有特性机制的增强与优化- task：与产品/服务相关的任务，可能不需要编码- discussion：发起一次针对特定话题的讨论，需要团队member积极参与- suggestion：针对产品/服务的建议，需要团队member参与review - proposal：针对产品某功能特性或非功能特性的技术提案，issue中通过markdown语法填写proposal的提案内容，供大家review
Selecting a category label for the issue is the premise and foundation for the subsequent flow of the workflow.
3) Select the version milestone
Choose a milestone for the issue you just created.
For bug, feature, enhancement issues, choose which version (milestone) to complete. For issues that have not yet been determined, you can put them in the backlog milestone, and then put them back into the version milestone later.
For issues of other category types, such as proposal and discussion, you can put the backlog first without selecting the version milestone.
4) Select the label of the workflow category
Next, we need to give it an appropriate workflow label according to the category of the issue, so that the issue enters the workflow.
- For bug-type issues
For bug-type issues, if it is unclear whether it is a bug or there is insufficient evidence, you can choose workflow/need-investigation or workflow/wait-for-info;
After investigation, if it is determined to be a bug, then a developer or leader needs to remove the workflow tag above, and then re-assign the workflow/confirmed tag. Only confirmed issues can be included in the version milestone for tracking, and bug issues without confirmed can be placed in the backlog milestone for confirmation;
If it is a duplicate issue, you can choose workflow/duplicate, and then we can close this duplicate issue;
For non-bugs or issues that do not need to be fixed after evaluation, you can choose workflow/wontfix, and then close the issue.
- For feature or enhancement class issues
If you need to do technical research, you can choose workflow/need-investigation;
If you need a technical proposal/design implementation plan, you can choose workflow/need-proposal;
If you need more information from the issuer, you can choose workflow/wait-for-info;
If you accept a feature or enhancement class issue, you can select workflow/accepted, and then confirm that it is in the correct version milestone.
- For proposal class issue
For proposal issues, the team needs to decide whether to accept the proposal. In the initial stage, you can choose workflow/need-review. After review, you can choose whether to accept it. If you accept it, choose workflow/accepted. Once accepted, you can choose which milestone to include. landing. If not accepted, then select workflow/declined (rejected), then close the issue.
Finally, for issues that cannot be continued temporarily due to various reasons, you can choose workflow/blocked. After the blocking problem is resolved, reselect the workflow label for the issue.
5) Select issue priority (optional)
Issues usually do not need to be prioritized. As long as the version milestone is included, it needs to be completed within the scope of the milestone.
However, we also customize some priority labels that need to be “focused” for flexible use.
- critical - 关键issue, milestone内必须要完成的- release-blocker - 通常针对bug类issue，如果该issue不解决，milestone无法按时完成和发布- security - 安全类issue，提升issue优先级- urgent - 紧急突发类issue，可以用于patch补丁的issue
6) Select component (optional)
Selecting the component class label for issue is more for statistical and filtering use. The logging, tracing, metrics, etc. here are for example only. You can define the necessary component tags according to your own product/project context.
7) Driven by workflow tags
After we complete a round of label assignment, the developer starts the follow-up work according to the status of the issue in the workflow. Once the work comes to an end, the workflow label of the issue will be changed until the issue is completed and closed.
3. Summary
This paper proposes a practical idea of software development driven by multiple label issues. Through this idea, a team can run organically around the issue tracing system.
If there are many issues and manual management is inconvenient, you can also introduce an issue bot to automatically maintain the status of the issue according to the set rules and remind you accordingly. I will continue to talk about this later if I have time.
4. References
- How to Use Issue to Manage Software Projects – https://ift.tt/RkuZ5KO
- The Complete Guide to Issue Tracking Best Practices – https://ift.tt/PT4Hwvn
- “Exploring the use of labels to categorize issues in Open-Source Software projects” – https://ift.tt/W7dx3Xs
- “An Empirical Study on Using Multi-Labels for Issues in GitHub” – https://ift.tt/jnyleiH
“Gopher Tribe” Knowledge Planet aims to create a high-quality Go learning and advanced community! High-quality first Go technical articles, “three-day” first reading rights, analysis of the current situation of Go language development twice a year, reading the fresh Gopher daily 1 hour in advance every day, online courses, technical columns, book content preview, must answer within six hours Guaranteed to meet all your needs about the Go language ecosystem! In 2022, the Gopher tribe will be fully revised, and will continue to share knowledge, skills and practices in the Go language and Go application fields, and add many forms of interaction. Everyone is welcome to join!
I love texting : Enterprise-level SMS platform customization development expert https://51smspush.com/. smspush : A customized SMS platform that can be deployed within the enterprise, with three-network coverage, not afraid of large concurrent access, and can be customized and expanded; the content of the SMS is determined by you, no longer bound, with rich interfaces, long SMS support, and optional signature. On April 8, 2020, China’s three major telecom operators jointly released the “5G Message White Paper”, and the 51 SMS platform will also be newly upgraded to the “51 Commercial Message Platform” to fully support 5G RCS messages.
The famous cloud hosting service provider DigitalOcean released the latest hosting plan. The entry-level Droplet configuration is upgraded to: 1 core CPU, 1G memory, 25G high-speed SSD, and the price is 5$/month. Friends who need to use DigitalOcean can open this link : https://ift.tt/Ew9QBoU to open your DO host road.
Gopher Daily Archive Repository – https://ift.tt/r4PqLix
my contact information:
- Weibo: https://ift.tt/mlrz8eX
- Blog: tonybai.com
- github: https://ift.tt/dnyckZp
Business cooperation methods: writing, publishing books, training, online courses, partnership entrepreneurship, consulting, advertising cooperation.
© 2022, bigwhite . All rights reserved.
This article is reprinted from https://tonybai.com/2022/08/12/practices-of-multi-label-based-issue-driven-software-development/
This site is for inclusion only, and the copyright belongs to the original author.