Curating issues

[timschofield]

Hi All,

We have had a number of issues reported which is great, and exactly what I was hoping for.

However this has led to me getting muddled. To try and bring some order to this I have created some labels to curate these issues.

These labels are

"Still to action"->"Action Proposed"->"Fix proposed awaiting test"->"Fix Confirmed awaiting closure"->"Closed"

The idea being that issues will move from left to right through these labels.

I have gone through the outstanding issues and attached a label to every one. I am happy to take any emndments to this system people may want.

Thanks
Tim

[dalers]

@timschofield from my perspective as more QA and user... , imho I think the labels could be tweaked. "Fixed proposed awaiting test" is just wrong because the commit has already been made to the master branch, and there's no need for a " Closed" label because the creator of the issue is satisfied their issue has been resolved and has closed it with a final comment.

Did you check for an existing best practices approach? I'm googling for a standard procedure or best practise as I type this, but I'd like to propose labelling issues first based on release, and second on status. I think the result will be more actionable and filterable (e.g. "what's left to do in v5 before we can have an RC-1?") by seperating project phase from status and the issues will naturally prioritize by being steered towards a release.

• From: To:
  • Still to action : no label (if it doesn't have a label, it's not actioned)
  • Action Proposed: v5 (i.e. issue MUST be resolved in v5.0.0 release), v5.x (i.e. sometime after 5.0.0), or v6 (i.e. for future consideration)
  • Fix proposed awaiting test : v5 (or v5.x, or v6) + "Testing"
  • Fix Confirmed awaiting closure: v5 (or v5.x, or v6) + Review"
  • Closed: no label (the creator, or perhaps someone else, closed the issue with a comment describing how the issue was resolved and preferably linking to a discussion topic).

I liked your "V5" page on the website, how about putting the list into order by release so it will match the issue labels? I'll try doing a quick first pass at assignment, which I'm sure will be wrong but will at least be a start..

[timschofield]

To be honest Dale I knocked this together in a few minutes because of my frustration in trying to track what is happening on the various issues. Am happy to go with your suggestions. However I'm not sure of the need for a version number in the label. My idea was that these labels would be be transitory, and just intended to show the path of the issue. All v5 issues should be closed before v5.1 existed, and so adding the version number to the label would just seem to add complexity.

Thanks
Tim

[dalers]

I complete understand not triaging issues just creates chaos. If I understand you correctly, issues that will be resolved "later" would simply not be labelled, and negate the need for my proposed "v5", " v5.5" and "v6" labels. Do I understand you correctly? My thinking is that when you read an issue, instead of triaging to simply "now" or "later", in effect you would triage to "in the next release", "after the next release" and "sometime later", which I think would reduce confusion and aid planning. Getting the most value possible from the initial review (without adding undue overhead) will reduce work later. I still need to finish seeing how others manage this....

[timschofield]

I think I prefer something simple with a small number of issues - I have removed some that I consider superfluous. If we had a version number in the issue name it might end up with lots of issues to choose from.

[timschofield]

"I liked your "V5" page on the website, how about putting the list into order by release so it will match the issue labels? I'll try doing a quick first pass at assignment, which I'm sure will be wrong but will at least be a start."

You should have access to the wiki page, please feel free to amend it.

[dalers]

You should have access to the wiki page, please feel free to amend it.

Done. https://github.com/timschofield/webERP/wiki/V5

I'm essentially proposing the highest priority for 5.0.0 is to be compatible with PHP8.1 and include the features you have already implemented, tested and have no related open issues, and that any open issues - with the exception of PHP8.1 compability - are of lower priority and will be resolved in either v5.1 or v6.0 (I put Journal Templating System and New budget system into v6 simply because I don't recall hearing much about them, perhaps there are actually no "v6" features...)"

[timschofield]

Journal templating and new budget system are actually done, and are in the master branch :)

[efeoli]

Hi Tim,
the CSS class noPrint wasn’t labeled, so please know that it is solved and all columns show and work adequately.
Enrique

[pakricard]

Hi:

As we are a small team project, I guess the KISS approach will work better. IMHO, having labels stating the life cycle of the issue is probably the simplest and best in our case, mainly Tim's proposal.

I tested #243 and tried to change the label assigned to it, but couldn't. What I could do it to close the issue as it has been properly fixed and tested.

Now issue #243 appears as closed but "fix proposed awaiting test". I couldn't sort it out.

[dalers]

tried to change the label assigned to it, but couldn't.

I found the same thing. Presumably only Tim currently can add or edit issue labels, which he will have to do based on the issue or comments to it.

However, I still don't like "Fix proposed awaiting test" on the basis that a commit is much more definate than a proposal, and suggest it be changed to "Fix committed awaiting test".

[timschofield]

Thanks Ricard I have removed that label. I will look into how you can do it Thanks Tim

…

On Mon, 18 Nov 2024 at 23:37, pakricard ***@***.***> wrote: Hi: As we are a small team project, I guess the KISS approach will work better. IMHO, having labels stating the life cycle of the issue is probably the simplest and best in our case, mainly Tim's proposal. I tested #243 <#243> and tried to change the label assigned to it, but couldn't. What I could do it to close the issue as it has been properly fixed and tested. Now issue #243 <#243> appears as closed but "fix proposed awaiting test". I couldn't sort it out. — Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL6LFYS6V3KTGWYIPBTQT2BJ25DAVCNFSM6AAAAABR73UO2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZG44TSMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- www.weberp.org <http://www.weberpafrica.com> @TimSchofield2 Blog: https://kwamoja.home.blog/

[timschofield]

Thanks for your help on this Enrique Tim

…

On Tue, 19 Nov 2024 at 00:37, efeoli ***@***.***> wrote: Hi Tim, the CSS class noPrint wasn’t labeled, so please know that it is solved and all columns show and work adequately. Enrique — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- www.weberp.org @TimSchofield2 Blog: https://kwamoja.home.blog/

[timschofield]

I have sent collaborator invites to Dale, Enrique and Ricard which should allow you to change labels.

[pakricard]

I have sent collaborator invites to Dale, Enrique and Ricard which should allow you to change labels.

Thanks, @timschofield . I can edit labels now

[dalers]

Thanks @timschofield

[dalers]

I "adjusted" the label names. What do you think? Better? I'll change them back if I'm out voted.

[timschofield]

They look good to me Dale

…

On Wed, 20 Nov 2024 at 01:08, Dale Scott ***@***.***> wrote: I "adjusted" the label names. What do you think? Better? I'll change them back if I'm out voted. — Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL6LE2DTTZ3IK3ZAT6B2L2BPOJVAVCNFSM6AAAAABR73UO2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZRGU4DOMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- www.weberp.org <http://www.weberpafrica.com> @TimSchofield2 Blog: https://kwamoja.home.blog/

[pakricard]

Hi @dalers:
I assigned myself the issue #304, and wanted to label it as “Fix on the way” or something similar, for everybody to know, I will fix it, but it is not yet done, it is on my to-do list, etc.
II miss a label to denote the status before “Fix committed needs testing”.
Which is the proper label for it?
P.S. Most probably I am getting lost in translation here,

[dalers]

Hi @pakricard Imho, no label is needed. Assigning the issue to yourself is sufficient to inform others you will be resolving it.

I would presume if an issue is assigned to someone it is their responsibility to resolve and I should not get involved (unless perhaps it was something extremely critical to myself and I couldn't wait, and then I should discuss with you or at least assign the issue to myself)

[dalers]

It's not easy to be simple...

Fwiw the Nextcloud project has what they call an "FR" which means "Feature Requests". An FR is really an GitHub Issue with the "Enhancement" label.

Also fwiw, here are the "default" labels GitHub provides i.e., recommends - if you don't have a better system.

Now having more experience managing issues, you think it would be useful to add any of these labels for use in the webERP repo? For me, I'd like a way to keep good suggestions but also be able to filter and see just the Issues needing to be resolved for a v5 release. What do you think?

https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels