Would this loop back to something like lib.maintainers in nixpkgs? I think a top-level maintainer list that is imported by our instance of packages (instead of something that lives in the pkgs repository) makes a lot of sense.
1 Like
I’d imagine we include auxolotl/community as an input of auxolotl/top-level alongside everything else, and pass it down to flakes as needed, yeah (more details on structure here).
1 Like
Instead of having the names in a let block, could we all have individual files that follow a username.nix naming scheme and then we can loop through all those files to generate the maintainers list? 
2 Likes
Just to be clear your suggesting that each sub level (e.g. auxolotl/javascript) were to declare their own maintainers.nix and that would utilised by top-level to merge all those lists together.
Because if thats not the case and we are defining it like so
{
core = import ./core/usernames.nix;
javascript = import ./javascript/usernames.nix;
}
Would be incredibly slow.
2 Likes
Just to be clear your suggesting that each sub level (e.g.
auxolotl/javascript) were to declare their ownmaintainers.nixand that would utilised by top-level to merge all those lists together.
Yep, that’s what I was going for.
2 Likes
the way I’m currently splitting is like so:
let
sigs = import ./sigs.nix;
users = import ./users.nix;
in [
{
sig = sigs.documentation;
leaders = [
users.coded
];
members = [
users.minion
users.discourse_test1
users.discourse_test2
];
}
]
this is non-ideal, for reasons like
- It would be nice to give CODEOWNERS (or equivalent) to each SIG so that they could be pulled in for review on changes to their SIG membership lists
- The users file will get really, really long
I think I’m going to tidy up a little, then commit and push something. We can look a little later at changing the format (either by writing some slicker python or some nix that outputs the same thing)
2 Likes
My biggest concern is how long eval will take with all those import’s
2 Likes
I don’t think it will be too bad, but if it is then we can always change it.
3 Likes
That would indeed be very cool 
2 Likes
Ahh, my apologies, I missed that. I’ll move the repo
2 Likes
But, yes, as Isabel says I got a thing up, it’s here: GitHub - auxolotl/community
Here’s my TODO list
- GitHub support
- Syncing roles for already-present members
- Inviting new members to the organization
- CI to run this on commit to main branch
- Better data format as discussed in this topic (+CODEOWNERS)
- Testing, testing, testing
- Up-to-date data
I would encourage you to give it a look over/make pull requests/etc. Please feel free to assign me to review them.
If you don’t have a discourse instance to test on, congratulations, it’s your lucky day! Here’s an invite link to my testing site: https://discourse-staging.starrysky.fyi/invites/vsB8VCs1kH
There’s also an admin account you can login to, email is discourse+test1@starrysky.fyi, password is discoursetest1
Please make your own testing groups, accounts, API keys, etc. on there if you want to test. Use the admin account to give yourself admin rather than as your main account. Please don’t nuke the instance, I’ll be sad. And I’ll rollback.
4 Likes
might be a bit late to the party, but i think axel was on to something earlier with individual maintainers lists
in the context of using multiple repos for different SIGs, having a centralized doesn’t make much sense. for example: in order to create a new package and add myself as a maintainer, i would need to create a PR to not just auxolotl/javascript with that package, but also auxolotl/community. auxolotl/javascript would then need to update it’s version auxolotl/community, and then my PR can be merged
i think the scaling issues is evident here; not to mention making a hard requirement for yet another repository besides core for each SIG
i propose that each SIG keeps it’s own maintainers list. this would allow for faster merges (as one SIG has a better chance at handling it’s own maintainer files updates rather than a single repo for everyone), an easier contributing experience (that is also similar to nixpkgs), limits our dependency bloat across the board, and keeps our repositories as independent as possible (a really important strength i think we can have in the future)
this could be implemented like so
# members-list.nix in auxolotl/rust
# could also be two files like nixpkgs but /shrug
rec {
users = {
getchoo = { name = "Seth"; githubId = "48872998"; forum = "getchoo"; };
};
leaders = with users; [
getchoo
];
}
# flake.nix for auxolotl/rust
{
inputs.core.url = "github:auxolotl/packages";
outputs = { core }: {
auxMembers = import ./members-list.nix;
};
}
# flake.nix for auxolotl/top-level
{
inputs = {
core.url = "github:auxolotl/packages";
rust = {
url = "github:auxolotl/rust";
inputs.nixpkgs.follows = "core";
};
};
outputs = { core, rust }: {
# ...
auxMembers = {
rust = { inherit (rust) auxMembers };
};
};
}
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
1 Like
My initial concern is that we’re (potentially) duplicating information about members across different places, which opens the potential for information mismatches in some places (eg. I update my email in one repo, but not the other - which is current?). I also like the idea of having a central, machine-readable place to get a map of the entire Auxolotl org. It’s the sort of thing that could be pretty useful for eg. creating documentation pages that stay up to date with SIG membership.
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. I think it’s pretty important for SIG leads to have a presence in the community, and to be able to communicate with users to understand their needs from what their SIG provides. Maybe not a discussion for this thread - open to hearing thoughts from others on this though.
3 Likes
core could cover this, as all of our other repos should depend on it
from my post:
auxMembers = {
rust = { inherit (rust) auxMembers };
};
would be present in the top-level
this is a separate issue that needs to be addressed then
does github not provide this? i completely understand the value of a forum, but i don’t think it should be the primary (let alone only, as it really is right now) way to communicate and organize around technical issues. github is much better suited for this with issue tracking, milestones, commit referencing, etc., as well as being the platform used to actually resolve anything. if the forum is the only place to get this information, i would consider that a pretty big mistake and not very welcoming to contributors (who won’t be lurking on the forums usually). like you said though, this is probably a discussion for another thread
1 Like
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.
2 Likes
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
1 Like
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?
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!
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.
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
1 Like
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 
5 Likes