Add new labels for Issues/PRs ICANN and PRIVATE

[dnsguru]

Hi- I would like to have two new labels for Issues and PRs - ICANN and PRIVATE, so that these can be added in reviewing them, so it is possible to visually skim through and visually identify them. Any resistance? -J

[sleevi]

It’s unclear how these would or should be treated differently. Could you explain more how these labels would be useful? What might they result in something being done different?

The only substantial thing I can think of is whether we’re looking at DNS vs. the registries stated policy, since email should be a truly exceptional and rarely used thing, but I’m not sure I follow how the labels would help with that?

[dnsguru]

I should have been more clear - these are the color-tag labels used within github: Like I added

• question
• r=weppos
• waiting-followup

just now to this issue.

What I am proposing is that we can have two different colored tags (aka label) to visually indicate those requests for ICANN section and PRIVATE section visually in the listing on Github. Purely a UI thing, has nothing to do with the format or structure of the PSL file.

[sleevi]

Right, I understood that part, but was trying to understand how it would be used or useful? I figure there’s a problem trying to be solved, and I wanted to understand more about the problem than the proposed solution 😅

[dnsguru]

The "problem" ... perhaps a loose interpretation - maybe 'feature request' is more what this is - was having some manner to identify the which section that the PR/Issues are in - quickly, visually. Being able to quickly see this will help me reviewing these - whereas you and weppos are receiving email stream, I am not, so I have to hunt ... as we have not added me onto the email address distro.

[dnsguru]

thinking it through, it might let us quantify the ratio of private vs ICANN section requests so that we can make data driven decisions about volume or other aspects of the project

[sleevi]

I’m still confused, so apologies and thanks for bearing with me.

For reviewing issues, you can just subscribe to the project and GitHub will notify you of new issues as they come up. There’s nothing special there.

For dealing with ICANN-related issues, as has been mentioned previously, we really want things to happen on the issue, such as confirming the TLD operator’s policies by having them actually publish the policies, or through the DNS validation. Email is truly an exceptional process.

For distinguishing ICANN vs PRIVATE, that is not a distinction that should change how we manage or process the list; it’s a minor distinction for consumers. I am still uncertain what we would do differently, if, for example, we saw that 90% of requests were not ICANN-domains. If there is a concrete thing we need or process we would/should change, I’m certainly open, but that’s what I mean by trying to focus on the problem.

To give an example, I would explicitly like to avoid a situation where, for example, ICANN+waiting-folllowup lead to off-issue discussions/resolutions without having record of that. That is, I don’t want merges that are “Talked to X at the last ICANN meeting and they said this was OK”, because it should not be necessary to go to ICANN meetings to manage or scale the list. Hopefully that makes sense? 😅

[dnsguru]

I think we're pole vaulting over a grain of rice here.

I am [selfishly] seeking to have a visual indicator so I could flag the ones that seem related to "ICANN" TLDs in order to skim the issues/PRs visually and be able to identify them quickly.

Not wanting to have bias over one section or the other, I thought adding a label for PRIVATE also seemed democratic. And I have seen a couple that are both, oddly.

I literally just want to flag stuff to keep my volunteer cycles efficient

it should not be necessary to go to ICANN meetings to manage or scale the list.

I hear you. This was not the objective.

That said, there is not a 'developer' stakeholder group there - and awareness of PSL is not always high. Having me and/or Simone participating there at these is really beneficial to the project to spread awareness + aid in the dialog and untangle matters when the IANA contact is not responding on a validation.

[sleevi]

I think we're pole vaulting over a grain of rice here.

I apologize if it feels like that. I wanted to try and focus on helping you solve whatever problem you perceived, rather than just opposing the change, as I do.

I am [selfishly] seeking to have a visual indicator so I could flag the ones that seem related to "ICANN" TLDs in order to skim the issues/PRs visually and be able to identify them quickly.

I guess I’m still a bit confused or at a loss here for what happens. That is, imagine every issue gets tagged (setting aside the work and timeliness). What would happen if you saw an ICANN issue? What would you do?

If they’re prioritized differently, I think that’s a net negative for the project. If they’re used to justify out-of-band contact rather than a consistent validation process, I think that’s a net negative for the project.

I don’t think I’ve really seen any issues that might have been particularly addressed by having direct contact. If any, our use of direct contact and evangelism has lead to new issues, like #924 or #977 after #744, which is unfortunate.

I literally just want to flag stuff to keep my volunteer cycles efficient

I totally understand, although I’m missing a key piece in understanding the challenges. If you want to tag ICANN issues informatively, I’ve got no concerns, but I’m not thrilled with the prospect that every maintainer now needs to triage additional labels, and ideally, all maintainers treat all issues equitably where viable.

What I’m missing, and this may just be obliviousness for work that’s going on behind the scenes, is how this would help efficiency. I’m perhaps blind to work being done here on the ICANN side that necessitates triaging, in part because I’ve never done that work for any of the PRs.

I’m definitely concerned about situations like https://github.com/publicsuffix/list/issues/671#issuecomment-586547560 and making sure we’re on the same page.

when the IANA contact is not responding on a validation.

I am not aware of this having happened, or where it would cause a problem? We very much want to avoid the IANA contact whenever necessary; it’s the last resort if and only if automatic validation fails.

[dnsguru]

@sleevi I understand your concerns - we share many, and I am trying to help (valuable team contrib) without trying to "help" (clumsy bored micro-manager) with the volunteer cycles.

I guess I’m still a bit confused or at a loss here for what happens.

I swear my request is literal - just seeking to use the label as a visual indicia like assigning a color to a label in gmail or the like. It had no other intent or meaning other than me wanting to quickly see of the requests that were around, which were related to the ICANN section and which the PRIVATE, and which were both.

I think I will close this - cosmetic stuff like this maybe is a bad idea.