Proposal: Pool of Label's for Issues
Hello folks, to bridge the time until we established contact with Germar I would like to make a proposal about a pool of labels for issues (the GitHub ticket system). This becomes relevant early when we start to re-triage all open issues to get a full overview and to find out what is urgent and burning. The goals I tried to archive are 1. All maintainers are restricted to a specific pool of labels. 2. Less is more! 3. Combinations allowed and welcome. 4. No need for labels to express close reasons. Explain the reason with words or links to a FAQ entry (or use your own predefined textblocks). 5. Especially "Wontfix" is not allowed because it is to broad and there is a high risk that this will be perceived as unfriendly and disrespectful by users and potential contributors. This is the tag pool (in Org mode syntax): - High priority :: Self explaining. Example: Relevant for next and near release or a security issue. - Medium priority :: See above. - Low priority :: Not urgent but relevant. - Feature :: Feature request. - Bug :: A bug. - Meta :: Collecting other issues (via reference) about a broader or more complex topic. Example: Improve documentation. - Gui :: Relevant to the GUI. This is about Qt and not about interfaces in generall. - user-callback :: Relavent to the user-callback feature. - Docu :: Issues relevant for documentation only. - Needs discussion :: Means /undecided/ (which would be to negativ). Topics that are hard to decide and need further discussion between all maintainers and contributors. For example the "EncFS/GoCrypFS-Discussion". - Feedback :: The topic will be closed if the questioner does not provide feedback within a certain period (e.g. 2-4 weeks). The label is for very old topics that seem to be no longer relevant, but we politely ask again. - Extern :: Something we should keep open but can not be solved by ourselfs. For example problems related to specific Linux distros or to one of our dependencies where we have to wait for a bugfix. I'm looking forward to your feedback and additions. Christian
Thank you, Christian! On 07.09.2022 09:40, c.buhtz@posteo.jp wrote:
I fully agree with your goals for our Labels in re-triaging all GitHub Issues. At the moment, I'm guilty of increasing the number of labels, not making it smaller ;) This is because I've been trying to get a feeling for the labels we might need and creating some new ones while browsing through the issues. In the near future, I will be consolidating and deleting old labels, and we should end up with a small, useful set. Note: There exists a backup of all Issues and their associated Labels from a few weeks ago, so that we can recover from mistakes I might make while re-organizing labels. I think we can't anticipate all the Labels we might need in advance, but here we have a very good rough guideline. I have just a few comments on Christian's suggestions:
I fully agree with these :)
- Bug :: A bug.
I think we could use a little more detail here. Additional labels to qualify bugs might be: - "Reproduced" (meaning: there is a known way to reliably make this bug appear -- logically, this should be the opposite of "Feeback"), - "Distro-Specific", as we've recently seen with Manjaro and PolicyKit (#931), as well as Arch and DBus (#1233). This is different from "Extern", because it's still our responsibility, but only affects certains distros. - "Mystery" - only half kidding ;) You know, there are Heisenbugs, and bugs which are believably real, but cannot be reproduced, or bugs that would be "High priority", if only they could be confirmed. I think such a Label might be useful. Another additional label we should use is "Testing", for everything related to unit-testing, coverage, virtual machine testing etc.
- Docu :: Issues relevant for documentation only. - user-callback :: Relavent to the user-callback feature.
Note that there are separate repositories concerning these topics: - https://github.com/bit-team/user-callback (example scripts only) - https://github.com/bit-team/doc I'm not sure how best to handle these. Transferring Issues from one repository to another is possible in principle – but it feels rude, and probably won't help in keeping a good overview of what's happening. But this might be a smaller problem for the future. Right now, we should set up a good set of Labels to help with triage, which is next on my to-do list :) Cheers, Michael
Dear Michael and Folks, Am 07.09.2022 12:32 schrieb Michael Büker:
Good approach.
- Bug :: A bug.
I think we could use a little more detail here.
Good idea.
- "Reproduced" (meaning: there is a known way to reliably make this bug appear -- logically, this should be the opposite of "Feeback"),
Yeah, very good. Makes a better feeling when the number of "Reproduced" issues is increasing. ;)
- "Distro-Specific"
OK.
I vote for "Heisenbugs"! Really! For sure! Im Ernst.
Another additional label we should use is "Testing", for everything related to unit-testing, coverage, virtual machine testing etc.
Not sure here. Unittests are implicit to all Issues and code changes. In a perfect world we only merge/commit when all tests are green. The other points you mentioned are "Infrastructure". Is that a good label?
I saw that "doc" doesn't offer an Issue tracker. But "user-callback" does. Now we redirect all Issues to "backintime" repo and centralize that.
Transferring Issues from one repository to another is possible in principle
No need for this. Kind Christian
Hi, all! Okay, so let me summarize our first approximation for a set of Labels. I came up with two additional ones: "Python-Version" and "cron". Priority labels: - High priority (relevant for coming release and/or security-related) - Medium priority - Low priority (relevant, but not urgent) Categories of Issues: - Bug - Feature (feature requests and improvements) - Infrastructure (coverage, testing etc.) - Meta (high-level discussions and/or collections of other issues) Bug categorization: - Reproduced - Heisenbug - Distro-Specific - Python-Version (troubles with _certain versions_ of Python) Affected components: - GUI (Qt) - Doc (documentation) - user-callback (scripting support, capabilities and examples) - cron (all aspects of scheduling) Status: - Discussion (can't move forward until decisions / consensus is made) - Feedback (will be closed within ~weeks unless reporter provides further information) - External (relevant, but can't be fixed / worked around by ourselves) Thanks for the good discussion :) Michael On 07.09.2022 17:05, c.buhtz@posteo.jp wrote:
Hi Everyone, I want to also add some suggestions to that list. Since we're both concerned with data security and want to tame this codebase, we can make use of some other labels, I think. All are open to debate, of course. Priority: - Blocker: Prevents release of the next version. - Critical: Reserved for data loss bugs. * We can also use Debian's categorization, detailed in [0] Categories: - Codebase: Refactoring and codebase organization. Affected Components: - rsync/rdiff - Encryption - Remote * We can collect all of them to "Backend". Bug categorization - Invalid: We all report wrong bugs, sometimes. - Wontfix: We may want to leave it like that. Status: - Triaged: We accept that it's a bug, we're looking into it, please wait. * Reproduced can be moved here. I agree with anything absent from the list. Also, we can design a workflow around these states and streamline how we do these things. Lastly, I think we need a bug report template. I can write a simple one if you want, tomorrow probably. Cheers, Hakan [0]: https://www.debian.org/Bugs/Developer#severities On Wed, September 7, 2022 22:19, Michael Büker wrote:
Thank you for your suggestions, Hakan! I'll keep them in mind while working through the Issues. I'm going to post a new thread here, with my suggestions on how to continue with re-Labelling and triaging all open tickets. Cheers :) Michael
Good morning together, the issue counter is in a free fall.... :D
Affected components:
Labels like that won't help me with maintaining. I would use labels to get an overview of different types of issues and there priorities. There is a difference between "type of a ticket" and "type of its content/topic". I would use labels only for the first type. The affected components should be described in the title of a ticket. It is like a question on stackoverflow: It helps a lot when you have a good and self explaining title. Then you know whats going on without even reading the content of the tickets. I only would like to have an exception for Back In Time parts/components like GUI/Doc/user-callback. IMHO to much labels do interrupt maintaining. Have a great day Christian
Sorry, my English. ;) What I meant in short: IMHO labels shouldn't reflect technical details (e.g. components or backend) of an Issue. This doesn't help (me) with management.
Good morning! On 08.09.2022 07:54, c.buhtz@posteo.jp wrote:
Okay, I get your point. I think "technical-content-Labels" might be useful in the future, and for some simple topics (like "Cron") they probably don't hurt now. But I agree: We shouldn't spend our energy on them right now.
Yes, I've been trying to rename tickets to have useful descriptions in the title. It's slow work, but once all the tickets have been "touched" by us at some point, we'll also have a much better overview.
Agreed :) Cheers! Michael
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be
Hi Christian, I understand you completely, however sometimes a bug migrates from component to component during traige/debugging process. We need a way to keep track of that. Component labels are useful, but I won't be holding to that idea strongly. Maybe we can think of categories here, and add components to the list, but do not introduce them to the tracker until they prove themselves to be needed. In fact, we can gradually add new labels to the mix, step by step. This will both easier, and more robust on the long run. Citing Gall's Law (which I love): true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. Cheers, Hakan P.S.: Don't be sorry about your English. It's very readable and understandable. On 8.09.2022 08:54, c.buhtz@posteo.jp wrote:
Thank you, Christian! On 07.09.2022 09:40, c.buhtz@posteo.jp wrote:
I fully agree with your goals for our Labels in re-triaging all GitHub Issues. At the moment, I'm guilty of increasing the number of labels, not making it smaller ;) This is because I've been trying to get a feeling for the labels we might need and creating some new ones while browsing through the issues. In the near future, I will be consolidating and deleting old labels, and we should end up with a small, useful set. Note: There exists a backup of all Issues and their associated Labels from a few weeks ago, so that we can recover from mistakes I might make while re-organizing labels. I think we can't anticipate all the Labels we might need in advance, but here we have a very good rough guideline. I have just a few comments on Christian's suggestions:
I fully agree with these :)
- Bug :: A bug.
I think we could use a little more detail here. Additional labels to qualify bugs might be: - "Reproduced" (meaning: there is a known way to reliably make this bug appear -- logically, this should be the opposite of "Feeback"), - "Distro-Specific", as we've recently seen with Manjaro and PolicyKit (#931), as well as Arch and DBus (#1233). This is different from "Extern", because it's still our responsibility, but only affects certains distros. - "Mystery" - only half kidding ;) You know, there are Heisenbugs, and bugs which are believably real, but cannot be reproduced, or bugs that would be "High priority", if only they could be confirmed. I think such a Label might be useful. Another additional label we should use is "Testing", for everything related to unit-testing, coverage, virtual machine testing etc.
- Docu :: Issues relevant for documentation only. - user-callback :: Relavent to the user-callback feature.
Note that there are separate repositories concerning these topics: - https://github.com/bit-team/user-callback (example scripts only) - https://github.com/bit-team/doc I'm not sure how best to handle these. Transferring Issues from one repository to another is possible in principle – but it feels rude, and probably won't help in keeping a good overview of what's happening. But this might be a smaller problem for the future. Right now, we should set up a good set of Labels to help with triage, which is next on my to-do list :) Cheers, Michael
Dear Michael and Folks, Am 07.09.2022 12:32 schrieb Michael Büker:
Good approach.
- Bug :: A bug.
I think we could use a little more detail here.
Good idea.
- "Reproduced" (meaning: there is a known way to reliably make this bug appear -- logically, this should be the opposite of "Feeback"),
Yeah, very good. Makes a better feeling when the number of "Reproduced" issues is increasing. ;)
- "Distro-Specific"
OK.
I vote for "Heisenbugs"! Really! For sure! Im Ernst.
Another additional label we should use is "Testing", for everything related to unit-testing, coverage, virtual machine testing etc.
Not sure here. Unittests are implicit to all Issues and code changes. In a perfect world we only merge/commit when all tests are green. The other points you mentioned are "Infrastructure". Is that a good label?
I saw that "doc" doesn't offer an Issue tracker. But "user-callback" does. Now we redirect all Issues to "backintime" repo and centralize that.
Transferring Issues from one repository to another is possible in principle
No need for this. Kind Christian
Hi, all! Okay, so let me summarize our first approximation for a set of Labels. I came up with two additional ones: "Python-Version" and "cron". Priority labels: - High priority (relevant for coming release and/or security-related) - Medium priority - Low priority (relevant, but not urgent) Categories of Issues: - Bug - Feature (feature requests and improvements) - Infrastructure (coverage, testing etc.) - Meta (high-level discussions and/or collections of other issues) Bug categorization: - Reproduced - Heisenbug - Distro-Specific - Python-Version (troubles with _certain versions_ of Python) Affected components: - GUI (Qt) - Doc (documentation) - user-callback (scripting support, capabilities and examples) - cron (all aspects of scheduling) Status: - Discussion (can't move forward until decisions / consensus is made) - Feedback (will be closed within ~weeks unless reporter provides further information) - External (relevant, but can't be fixed / worked around by ourselves) Thanks for the good discussion :) Michael On 07.09.2022 17:05, c.buhtz@posteo.jp wrote:
Hi Everyone, I want to also add some suggestions to that list. Since we're both concerned with data security and want to tame this codebase, we can make use of some other labels, I think. All are open to debate, of course. Priority: - Blocker: Prevents release of the next version. - Critical: Reserved for data loss bugs. * We can also use Debian's categorization, detailed in [0] Categories: - Codebase: Refactoring and codebase organization. Affected Components: - rsync/rdiff - Encryption - Remote * We can collect all of them to "Backend". Bug categorization - Invalid: We all report wrong bugs, sometimes. - Wontfix: We may want to leave it like that. Status: - Triaged: We accept that it's a bug, we're looking into it, please wait. * Reproduced can be moved here. I agree with anything absent from the list. Also, we can design a workflow around these states and streamline how we do these things. Lastly, I think we need a bug report template. I can write a simple one if you want, tomorrow probably. Cheers, Hakan [0]: https://www.debian.org/Bugs/Developer#severities On Wed, September 7, 2022 22:19, Michael Büker wrote:
Thank you for your suggestions, Hakan! I'll keep them in mind while working through the Issues. I'm going to post a new thread here, with my suggestions on how to continue with re-Labelling and triaging all open tickets. Cheers :) Michael
Good morning together, the issue counter is in a free fall.... :D
Affected components:
Labels like that won't help me with maintaining. I would use labels to get an overview of different types of issues and there priorities. There is a difference between "type of a ticket" and "type of its content/topic". I would use labels only for the first type. The affected components should be described in the title of a ticket. It is like a question on stackoverflow: It helps a lot when you have a good and self explaining title. Then you know whats going on without even reading the content of the tickets. I only would like to have an exception for Back In Time parts/components like GUI/Doc/user-callback. IMHO to much labels do interrupt maintaining. Have a great day Christian
Sorry, my English. ;) What I meant in short: IMHO labels shouldn't reflect technical details (e.g. components or backend) of an Issue. This doesn't help (me) with management.
Good morning! On 08.09.2022 07:54, c.buhtz@posteo.jp wrote:
Okay, I get your point. I think "technical-content-Labels" might be useful in the future, and for some simple topics (like "Cron") they probably don't hurt now. But I agree: We shouldn't spend our energy on them right now.
Yes, I've been trying to rename tickets to have useful descriptions in the title. It's slow work, but once all the tickets have been "touched" by us at some point, we'll also have a much better overview.
Agreed :) Cheers! Michael
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be
Hi Christian, I understand you completely, however sometimes a bug migrates from component to component during traige/debugging process. We need a way to keep track of that. Component labels are useful, but I won't be holding to that idea strongly. Maybe we can think of categories here, and add components to the list, but do not introduce them to the tracker until they prove themselves to be needed. In fact, we can gradually add new labels to the mix, step by step. This will both easier, and more robust on the long run. Citing Gall's Law (which I love): true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. Cheers, Hakan P.S.: Don't be sorry about your English. It's very readable and understandable. On 8.09.2022 08:54, c.buhtz@posteo.jp wrote:
participants (4)
-
c.buhtz＠posteo.jp -
Hakan Bayindir -
Hakan Bayındır
-
Michael Büker