Triage team

[wdhdev]

I was thinking, what if we had a sort of triage team who labels PRs/issues? The main benefits would be it would reduce what maintainers have to do to very little, mainly only merging and possibly commenting on some issues.

If possible, could @groundcat and myself could get triage permissions, so when we review PRs/comment on issues, we can label them accordingly?

[simon-friedberger]

I support this. You're doing good work and if you could add labels the ticket states would be more obvious.

(The team already exists, afaik)

[weppos]

To confirm, you want @wdhdev and @groundcat to be added to the existing Triage team?

[simon-friedberger]

@weppos I think so but I cannot see team permissions so you will have to decide.

(You can, of course, make me an admin, then I can take care of it.)

[wdhdev]

@weppos @simon-friedberger FWIW, if it is a team on the organisation, I believe we would need to be added to the organisation so we can be added to the team, as I don't believe external members can be added to organisational teams.

Or you can manually set the triage permission per individual user in the repo settings.

[wdhdev]

Hey all, any updates on this?

[dnsguru]

ok so #2250 and #2248 give me some pause

These appeared to have changes being submitted to IANA delegated ccTLDs as if they were changes from the ccTLD, but instead were added from non-trusted third party sources either site:.foo or wikipedia.

ccTLDs need to specifically ONLY be updated by the ccTLD administrator or have their info updated to synchronize with a clearly verifiable source that follows the URL visiting path from IANA.org to the respective registry listed in the IANA TLD DB, and then cites the page on that registry which lists that namespace change.

Before we open up to more people with essentially merge rights, I want to push us to preserve the integrity of the changes and what happens in the ICANN section at the top section.

[dnsguru]

I support this. You're doing good work and if you could add labels the ticket states would be more obvious.

(The team already exists, afaik)

I agree good work is happening but there was some room to improve before opening this up.

[wdhdev]

ok so #2250 and #2248 give me some pause

These appeared to have changes being submitted to IANA delegated ccTLDs as if they were changes from the ccTLD, but instead were added from non-trusted third party sources either site:.foo or wikipedia.

ccTLDs need to specifically ONLY be updated by the ccTLD administrator or have their info updated to synchronize with a clearly verifiable source that follows the URL visiting path from IANA.org to the respective registry listed in the IANA TLD DB, and then cites the page on that registry which lists that namespace change.

That is understandable, I apologise on my part.

I will attempt to contact the ccTLD operators to see if they can confirm if any updates to their sections are required.

In future, I'll ensure to get these updates from trusted sources (the operators themselves or the registry website.)

I agree good work is happening but there was some room to improve before opening this up.

Do you have any suggestions on how I/we can improve?

[groundcat]

Before we open up to more people with essentially merge rights, I want to push us to preserve the integrity of the changes and what happens in the ICANN section at the top section.

@dnsguru I agree with you that any changes made to the ICANN section should either use authoritative sources (starting from IANA database) or be confirmed by the registry, not by any third-party sources.

Regarding triaging, according to GitHub documentation on Repository roles for an organization, I think the triage permission does not allow merging a PR and does not include any write permission to the PSL text file. Therefore, the decision to merge or not would still remain with maintainers who have write permission, as a safeguard for the list. The triage permission is restrictive but sufficient for contributors adding tags to issues/PRs to improve efficiency without compromising the list’s integrity due to potential contributor oversights.

[mozfreddyb]

@dnsguru The ccTLD case you are mentioning is supported and widely understood as important process. I am confident that this won't happen again. The question here is about triage access. All we want is that our new volunteers can help set lables and pre-check issues so the burden on the people that review & merge is further reduced. Can you please reconsider?