Sub-team governance issue about ayo HOT 11 OPEN

A thought just occured to me while thinking about the autonomy of teams which is one of the coolest parts of our governance structure (imo):

When there isn't an explicit team assigned, there is a sense in which the whole community is the team, but interested and knowledgeable community members start to form a loose team. Take the Worker work being done at #58 . One underlying idea behind teams is to define the set of people with whom consensus around an idea is meaningful. That team is forming ad-hoc, and I'd like to explore what it means for that de facto team to become a de jure team, or if that's even useful.

from ayo.

Personally, I'm kinda ok with whatever structure will enable me to be more effective here.

I would like to reiterate a couple things about my involvement in Node.js:

• I was a sizeable contributor to the way structure, policy, and governance have been in Node.
• If I had better ideas on some of these things I'd probably have been working on them in Node over a year ago.

Node does a pretty good job on the commit-access end, IMO: "Made a couple commits? Get commit rights."

I personally am unsure how to open commit access more than that, so it is better of having the other Ayo folks figure that one out. But, at the very least or as a baseline, that does work.

(Aside: Commit access is required to manage the issue tracker. In the distant past I'd advocated for GitHub to separate those roles but the reality is that the issue tracker is more fragile than the git repository. The repo is easily recoverable for any mistake - everyone else has a full copy. This is not true for issue comments.)

As for teams...

Again, I could be the only or one of the only on at least a half dozen different node subsystems/core modules. That is just impractical in the near-forseeable-future, imo. We'd simply need more people.

However, I do think that team formation need to be more prominent and explicit. If it isn't, the result will just be that no one forms teams because they do not feel empowered to do so, and more likely than not core won't forms teams either, because there will be seemingly no one to fill them.

from ayo.

I, personally, don't feel like the language requires that teams be formed, it just assumes that they will form and gives some structure to those teams as they do form. The spirit of what (I believe) we're trying to accomplish is that everything is as lightweight, ad-hoc, and little-a agile as possible.

Maybe the language around the mandatory inclusion of a core team member is a bit daunting, but I do think that a team is not required for a PR, so no need to wait on this to be settled. I think teams will naturally form (like the website team), and it's a bit ambiguous when a group of people working on a subsystem magically becomes a team, so we definitely need to address that ambiguity.

from ayo.

To your point about doing more meta project stuff, we should try to come up with a more concrete story around that, too, but I think we can come up with a lighter-weight way of addressing that than making another distinct tier of contributor.

Core may decide to swell their ranks with people who present themselves as helpful in the ways you described (code review, triage, etc.). It's still an open question as to what role Core takes in the project in-the-role-of Core members, but I know the members of that team will be doing a lot of the same things you described.

from ayo.

But... there are a lot of folks like myself around Node/Ayo that don't work in specific confined areas but also do not specifically need to be in a leadership position for their work.

Following on a bit from @scotttrinh last post ⬆️, taking you as example, aside from some potential overhead would there be a problem with having you in multiple teams? (considering we'd like teams to be lightweight, low overheard things).

I don't think I'm against the idea of a general purpose core tech team / working group, but (for lack of a better description) it feels like the wrong abstraction?

from ayo.

I think we'll discover a lot about this once we get some more concrete ideas around the how/why/what of teams. I think we all have slightly varying definitions of what a team is, and precision on this will help.

Personally, I'd like for them to be as lightweight as possible and formed with as little ceremony as possible. The autonomy language certainly implies longevity, and makes a lot of sense for some teams that (somewhat by definition) will be around for the extent of the project's lifetime, e.g. website, release, social. But, I'm sure there will be more short-lived teams or ones that persist, but are not very active after an initial burst of activity.

What do we think is the best way forward for getting to the bottom of this? I'd like input from people not already on a team (looking at you @Fishrock123 😉) as to what (if anything) they would want to see. Need to discover what the real advantages of teams are and make sure they don't become needless (or dangerous) bureaucratic structures.

from ayo.

How about something like this, where we focus on getting teams up and running and functional as quickly as possible, with the bells and whistles handled more granularly by separate processes:

1. Encourage creation of ad-hoc 'teams' without requiring official recognition first. Treat these members are legitimate in the eyes of Core. That is, "I'm gonna start sending you PRs for this now, and if anyone wants to join me, I've made a channel on Discord so we can talk about it."
2. "Mechanical" teams are just that, in GitHub lingo: Core (or the relevant "parent" team) are able to create an @ayojs/some-team-name team, with initial team membership following policy, and team members added at the discretion of that team. These teams should in general not have any extra Github permissions.
3. Team members who wish to have commit rights should be added to an @ayojs/committers team, where the only requirement is "have been entrusted with commit rights and have gone through committer onboarding". They are otherwise no different from any other wider-community member. "onboarding" includes knowing to defer to the correct team for approval about whether a PR is ready for merging.
4. More specific sub-rights may be delegated from core/parent as needed (Travis permissions for ops/testing teams, website publish access for web team, etc). The team may create a sub-team dedicated to higher-user-privilege roles.
5. Cross-cutting concerns besides those managed by the above can be handled by allowing responsibility overlap within team: instead of exclusively "delegating", teams may agree to share responsibility with another. This can be as granular as the teams agree it to be, but more generous would be better.

...or something like that. I think this addresses a lot of the concerns about ad-hoc-ness and cross-cutting that @Fishrock123 brought up. I think "teams" as we've been treating it so far act more as rallying points for contributors, and I think that's a fantastic thing for them to generally do: I think the cases where governance really needs to kick in should be fairly rare: and I imagine it being largely about teams wanting more autonomy from Core (since they'll tend to be the more "permanent residents"), rather than trying to fight with each other about who "owns" what.

Recognition is important, and people like that, and it motivates them, so giving that out early and often is only bound to help. People don't necessarily mind waiting a little while before the "mechanical" bits are sorted out as soon as they can start talking about themselves as a group sooner rather than later. And really, making a team on github is ezpz.

from ayo.

@zkat

That sounds good to me. The original idea around having a core member on the team was so that core was aware of any concerns that might affect any decision-making process they were considering.

Maybe we can invert it when this comes up and say that in the event that core needs to make some project-level decision that may affect the existing teams, they reach out to those teams who do not already have a core member and invite a delegate from that team to represent that team's interests and purview? That's similar (the same as?) to your fifth point, I believe.

from ayo.

Thanks for the extra context @Fishrock123 , that was helpful!

RE: teams
I think we need to figure out what the benefits are of a group of people being officially recognized as a Team to figure out how/when best to apply them. Here are some of my thoughts to that end:

• Camaraderie
• Defines the who in consensus-seeking
• Allows people to specialize and feel a sense of ownership
• Gives people outside of the team an easy reference point for who they should talk to about something that would affect the purview of that team
• Allows us to experiment with alternative forms of sub-team governance (within the bounds of the overall project governance structure)

I'm sure there are many others, but these come to mind first.

The human scale of this project is still small, so it might make sense to have a concept of a two-person team or to use the idea of 3-person group as a trigger for creating a real Team around something. More concretely: if you can think of at least 2 other people you would explicitly put as reviewers on a collection of related issues you're working on, that might give us a practical reason to start to consider that group a capital-T Team?

from ayo.

Perhaps we should identify what areas are our weaknesses, then form empty teams for those things and do some sort of public Call For Members to encourage people to come forward and help out? Those of us already in the code will have a better idea where people can have the most impact than someone on the outside looking in.

from ayo.

My college professor says that there is a linear increase in efficiency for each additional layer of organizational bureaucracy. I think sub-teams are a great way to take advantage of this and we should even consider sub-sub-teams or n-sub-teams. Each would need its own n-sub-moderation-team to ensure each member has the same chance to be heard, of course.

from ayo.