Community tracking

[isabel]

@getchoo

@srxl

IMO, it would be quite difficult for a SIG lead to operate without being on the forum - at least right now, this is where a lot of our communication happens.

this is a separate issue that needs to be addressed then

This should be addressed soon by the creation of the matrix. And I personally think we should have points of contact like emails, matrix and the forum and maybe more. But you need at least 1.

[getchoo]

And I personally think we should have points of contact like emails, matrix and the forum and maybe more. But you need at least 1.

i think this would be a good compromise, especially with email as an optionx

[minion]

@getchoo

core could cover this, as all of our other repos should depend on it

Maybe I’m missing something, but I’m not sure of the difference between having to make a PR to maintainers and a PR to javascript vs having to make a PR to core and a PR to javascript… it seems to me that this only simplifies things when making PRs to core. Is this not the case?

Additionally, I’d be worried about people who did not specifically want to become SIG members but still wanted to be in the organization, where would they go? In core also?

@getchoo

i also find the forum integration a bit odd…imo it’d make sense to just do this through PRs, similar to nixpkgs. requiring a forum account to become a SIG lead for example might not be the best for everyone

This is already the case. If you don’t specify all of the account types, the script will silently ignore any you didn’t specify. I have not yet written documentation in a usable format, but I plan to. Thanks for highlighting it as a thing I need to mention!

@isabel

And I personally think we should have points of contact like emails, matrix and the forum and maybe more. But you need at least 1.

This is an excellent idea, in my opinion. I think if we can require as little as possible for someone to be a “maintainer” this is fantastic.

[getchoo]

@minion

but I’m not sure of the difference between having to make a PR to maintainers and a PR to javascript vs having to make a PR to core and a PR to javascript

i’m not entirely sure what you mean here? this isn’t what i described. if you are only making a PR to javascript to maintain a package in that repo, you would only need to make a PR there.

it seems to me that this only simplifies things when making PRs to core. Is this not the case?

no. core would only be involved in cases where you are maintaining multiple packages across multiple repos - which in that case i don’t think it’s unreasonable to expect PRs to separate repos, as the contributor would already need to be doing that. for a vast majority of cases where a contributor is contributing to a repo like rust or python, this only requires a single PR with two commits (one adding yourself to the member list, one for the package itself), similar to nixpkgs.

in contrast, relying on a completely separate repo always requires two coordinated PRs between the maintainer repo and any of the SIG/language-specific repos. this is a massive burden to put on any new contributor, which in turn could easily discourage newer contributors - especially those new to the foss space in general. i would also like the reiterate the potential delays in PRs due to waiting on the maintainer repo to merge your information, and then waiting for that update to hit your current repo and have your PR be rebased. once we get to a larger scale this will most definitely become an issue, as it forces us into a lockfile update (something i hope we can agree will probably be one of the more expensive things we can do in regards to syncing all of the repos) for every new maintainer

Additionally, I’d be worried about people who did not specifically want to become SIG members but still wanted to be in the organization, where would they go? In core also?

yeah, as regular users. this would be the same as joining the org to maintain a js package and adding yourself to a members list, but not joining the SIG itself

[minion]

i’m not entirely sure what you mean here? this isn’t what i described. if you are only making a PR to javascript to maintain a package in that repo, you would only need to make a PR there.

Ahhh, sorry, I didn’t get that … yes, I agree, this is a lot simpler in most cases then

forces us into a lockfile update … for every new maintainer

Yes, this is another excellent point, alright, I’m convinced, if we are to use this for package maintainers then we definitely need to have it split across repos

I had initially been approaching it only from a SIG/org membership point of view, so my ideas were largely constructed around it. You’re absolutely right, we would want to use this for maintainers too and the current ideas would become somewhat of a burden.

Back to the drawing board, I guess! I’ll look for something much closer to your suggestion up here: Community tracking - #18 by getchoo

Thanks very much for helping me understand your and Axel’s ideas