Proposal: we start tracking community members and team members in a similar way to kubernetes but with our own spin. This repository will also hold all transparency reports (moderation actions), meetings reports and more.
To start there are sevral diffrent ways of going about doing this the mains ones I’ve seen include:
To get us started i’ve created the repo, auxolotl/community · GitHub, but it is empty awaiting further discussion.
Also for those that are not staff, here is @minion proposal for maintainer tracking. I personally really like the idea here.
let
users = {
minion = { forum = "minion"; github = "minion3665" };
raf = { forum = "raf"; github = "notashelf" };
};
in {
SIGDocs = {
leaders = [
users.minion
];
members = [
users.raf
];
};
SIGCore = {
...
};
}
Nixpkgs also includes things like emails and GPG key ids - do we think this might be useful information here as well?
I’d also include an optional “fullName” field, for those who might want to have that listed.
Yeah the current template just a basic stripped to the barebones example. So I think it like you said is imperative that we import a lot of the fields such as fullname and emails like you said. Ideally we will enforce a 1+ points of contact too.
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.
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).
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? 
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.
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.
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
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)
My biggest concern is how long eval will take with all those import’s
I don’t think it will be too bad, but if it is then we can always change it.
That would indeed be very cool 
Ahh, my apologies, I missed that. I’ll move the repo
But, yes, as Isabel says I got a thing up, it’s here: GitHub - auxolotl/community
Here’s my TODO list
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.
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
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.
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