frequently asked question and other labels in the discuss repo

[JonathanGregory]

Dear all

I've taken the liberty of adding, clarifying and tidying (I hope) the descriptions of the some of the labels in this repo. We don't have a procedure for agreeing changes to labels, so it seems best to open this issue for discussion. Any of the changes I've made can be reversed, of course.

As well modifying descriptions, I have deleted documentation #0075ca, help wanted #008672, invalid #e4e669 and wontfix #ffffff, because none of these have been used in practice. I suppose they are GitHub standards, and they don't correspond to anything in the CF procedures.

Finally, I have renamed good first issue as frequently asked question. We have not used good first issue in this repo or the other CF repos. Instead, we provide templates which help users draft their issues. I propose that we could use frequently asked question to label issues which could usefully be covered by the CF FAQ list. We haven't updated this recently, but I believe that it's a useful resource, especially for new users, and could be made more useful by adding more to it. If others agree, we could add the same label in the other repos.

What do you think?

Cheers

Jonathan

[davidhassell]

Dear Jonathan,

Thank you for doing this - I think the new names and descriptions are much clearer. A few questions and comments:

• Removing good first issue is fine. I think that it is usually meant as an indication that it's a good issue to be solved by someone not contributed before.
• duplicate seems to me to be a duplicate of the new frequently asked question label.
• I'm not sure what the ENVRI-FAIR is for. Only 2 issues have it, which were closed nearly two years ago. Can we remove it?
• Could/should accepted also be applied to defects and enhancements?

Thanks,
David

[JonathanGregory]

Dear David

Thanks for considering this. I suppose that duplicate is meant to be attached if someone notices that it's essentially the same as some other issue that's also current. But maybe that's not the idea. I don't think we ever use it - should we abolish it?

I hadn't spotted that ENVRI-FAIR wasn't a label for any open issue - thanks. If those two have, or are given, the standard name label, I should think we can abolish that one too. Maybe Alison @japamment has a view on this?

Yes, I agree, accepted should be used to label defects and enhancements that have been agreed. It's useful to record that we've made a decision. Following that idea, we probably should use the black #000000 no change agreed label that we have in the conventions repo in this repo as well, when we decide against doing something, for the record.

Best wishes

Jonathan

[larsbarring]

Doesno change agreed mean

• no agreement on change, i.e. an issue that is open, and possibly gone dormant, without any agreement regarding what/how to change, or
• agreement to not change, i.e. and issue, open or closed, where there was agreement to not make a suggested change?
• Or maybe it means both, which seems less meaningful.

Presumably, in the first case the issue should not be closed. What might happen with an issue without agreement is however that it becomes obsolete because of developments to other aspects of the Conventions. Thus, would a label obsolete be useful to signal that a no-agreement issue nevertheless can be closed?

[feggleton]

Hi @JonathanGregory, thanks for your help on this. I'm happy with the ones you've changed so far that's fine. I would highlight that I need all of the labels that link to standard name table maintenance which are 'accept within 7 days', 'accepted', 'add to cfeditor', 'moderator attention' and 'standard name'. Some of them also link to the GitHub Actions so removing them would influence the automation. However the automation only applies to issues with the standard name label.

The 'ENVRI-FAIR' label was used for a specific project I believe who needed to submit a lot of standard name requests so Alison created a label to keep track of which were requests from that specific project. If it's not used or needed anymore I'm sure it's fine to be remove. Sometimes labels are needed only for a temporary use.

Thank you for adding the description to them too, very useful!

[JonathanGregory]

Dear Fran @feggleton

Thanks for your comments. I noted "(added automatically)" for add to cfeditor and moderator attention. That's right, isn't it? Are any others added automatically at present? Do you think we need to put any other warnings or notes in the descriptions of the ones that relate to GitHub actions?

I have deleted ENVRI-FAIR. The two issues which had this label also have standard name.

Best wishes

Jonathan

[JonathanGregory]

Dear @larsbarring

You are quite right to point out the ambiguity of no change agreed. I introduced this in the conventions repo, so it's my fault. It is intended to mean we have discussed the proposal and agreed not to implement any change. Would agreed to no change make sense to you? Or agreement not to change?

Though I can't remember for sure, I think we discussed, and possibly agreed, that it would be OK to close dormant issues after twelve months of silence, with an appropriate label attached, in the conventions repo. If agreeable, we could do the same in this and the website repo. What about not concluded or inconclusive, for instance?

Best wishes

Jonathan

[larsbarring]

Dear @JonathanGregory

I think either of the alternatives are fine, perhaps with an insignificant preference for the latter : agreement not to change. But I will be happy with either.

I think that closing of issues that have gone dormant should not be done without "due consideration". I am not quite sure what that means in practice, but here is a strawman:

1. After M months (M=2 or 3?) of silence the issue receives the label dormant and the moderator, initial poster (and others??) receives a reminder email.
2. If nothing happens in D days (D=?, or one month?) the issue additionally receives the label committee attention.
3. [A subset of] the Conventions Committee periodically reviews (say every 6 month?) the committee attention issues and have a brief github (and offline if necessary) interaction resulting in
   - labelling the issue as inconclusive and then closing it (perhaps after a 7 day cooling off period),
   - assigning a moderator (as most dormant issues do not have a moderator) to resurrect the discussion,
   - taking actions to initiate an offline group (probably happens only rarely),
   - realising that this is a difficult question that could be the topic for a CF workshop discussion or breakout theme, label CF workshop. If the Workshop does not pick it up as a discussion/breakout theme, it should at least decide what to do with the issue, which might labelling it as inconclusive (then see 1.) or something else.
   - something else ??

As you probably have guessed this was inspired by the excellent standard name automation that @feggleton has set up

[feggleton]

Dear Fran @feggleton

Thanks for your comments. I noted "(added automatically)" for add to cfeditor and moderator attention. That's right, isn't it? Are any others added automatically at present? Do you think we need to put any other warnings or notes in the descriptions of the ones that relate to GitHub actions?

I have deleted ENVRI-FAIR. The two issues which had this label also have standard name.

Best wishes

Jonathan

Great thanks. Yes i saw that. 'moderator attention' is added automatically. 'add to cfeditor' is added when using the standard name request issue template, as is 'standard name' although all could be added manually if required. Perhaps just add to 'moderator attention' the statement - added automatically as part of a GitHub Action.

Thanks

[JonathanGregory]

How's that?

[feggleton]

Perfect, thank you

[JonathanGregory]

If there are no further comments on this issue, concerning labels in the discuss repo, I will close it as completed on 1st June, which will be three weeks after the last comment. @larsbarring's last comment refers to the conventions repo, so I'll open another issue there. Jonathan

[larsbarring]

In fact , my comment referred to this repo, in which it is not infrequent that issues become dormant for whatever reason. But I agree with what @JonathanGregory writes in the transferred issue that handling of dormant issues preferably should be similar across the different repos. So, let's continue the conversation over there.

[JonathanGregory]

Sorry I jumped to the wrong conclusion that you were commenting on the conventions repo, Lars. You're right that standard name proposals go dormant as well, which are made in this discuss repo. But, as you say, the procedure should be similar. I'm closing this issue now, which I opened concerning labels in the discuss repo, on which we reached agreement and made changes three weeks ago. Jonathan