RFC 0002: IPFS governance structure (wip) #2
Conversation
flyingzumwalt
force-pushed
the
0002-ipfs-governance
branch
3 times, most recently
from
479a8d8 to
39abbab
Compare
flyingzumwalt
force-pushed
the
0002-ipfs-governance
branch
from
39abbab to
b767bc3
Compare
|
In the latest commit I've renamed Product Working Groups to Teams. Please comment if you disagree. Background: In previous iterations, we called everything a Working Group but distinguished between Product Working Groups (PWG) and Functional Working Groups (FWG). That language was really clunky. To make the language clearer, in the current version of the RFC I renamed Product Working Groups to Teams and renamed Functional Working Groups to just "Working Groups". Some of Drawbacks of calling everything a WG:
|
|
FYI, there's a sketch of the existing and proposed WGs in the Working Groups Lifecycle Management document. That sheet uses the PWG/FWG distinction that I'm proposing to replace with "Teams" and "Working Groups" |
|
Something I really enjoy and is helpful for keeping up with the work going on in different places is a newsletter like working groups in the rust world do, e.g: https://internals.rust-lang.org/t/the-embedded-working-group-newsletter-1/7053 |
There was a problem hiding this comment.
My general feedback is that it would seem that teams come with obligations (in terms of project and product management) but with little rights or support.
I understand that teams can run their backyard pretty much how they like, organize their time, their sprints, adopt methodologies as they need, and, in practice, significantly steer project's direction (withing limits, but still), but this is not expressed.
In my wishlist, is also that if a Team is created, a project-manager should be allocated to it from a PM team. This PM should help the team focus, help write and curate their OKRs and help aligning with other teams. Teams should also be able to get access to other cross-team resources like Designers, Event managers or HR. This happens in practice, so it should probably be stated (with a safe-guard about being a best-effort thing and depending on available resources).
In general I think this is OK for as starting point statutes. I don't have fundamental issues (no-gos) with it.
| - Working Groups occasionally define OKRs, but they don't have to define OKRs every quarter. | ||
| - Working Groups don’t necessarily subdivide when they get bigger. Unlike Teams, which are encouraged to form a tree of sub-teams when they grow bigger than ~5 people, Working Groups are able to convene larger groups of stakeholders. | ||
|
|
||
| ### The Core Working Group |
There was a problem hiding this comment.
I suggest to change this to something else than Core, as Core has different meaning in Protocol Labs and this may lead to confusion.
Coordination working group, Steering commitee/WG etc. would be clearer
| 2. Keep the Working Group lifecycle running smoothly | ||
| 3. Keep the RFC process running smoothly, delegating the decision making to Working Groups whenever possible | ||
|
|
||
| ### The Core Working Group is Responsible for |
There was a problem hiding this comment.
This section is essentially a dup from the three bullet points right above.
There was a problem hiding this comment.
Also, I prefer the three bullet points because there is less to read.
| - Core team can assign/delegate ownership of a product, library, spec, problem domain to a Team or WG, So that those groups can operate with clear mandates and healthy amounts of autonomy. | ||
| - In case of process failure or broken protocols among the teams, the Core Working Group is responsible for addressing the situation. | ||
| - They have the authority to institute short-term measures to address pressing problems/disputes | ||
| - They have the authority to fast-track RFCs that amend broken processes or protocols. |
There was a problem hiding this comment.
Maybe we can get a short list of what the Core working group cannot do, or things which are not among their prerogatives.
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| ## Size and Maturity of the Projects |
There was a problem hiding this comment.
If all the text accompanying each of the motivation entries disappeared, and the Motivation section was just a list with 4 bullet points I wouldn't mind.
There was a problem hiding this comment.
To clarify, there are 3 parts in this document:
- A part to set a context and try to convince readers why it's good to do this
- A part to explain concepts
- A part to set rules
I think the first part (motivation) belongs more to the discussion than to the document itself. The document could have a pointer to it though.
|
|
||
| We want Teams and Working Groups to emerge, function, and dissolve in response to community needs. To accommodate this, Teams and Working Groups are created using the RFC process -- people who want to form a Team or Working Group must propose it in an RFC and get that RFC merged. That open-ended invitation to create Teams and Working Groups is matched by clear protocols describing when and how working groups should be dissolved. | ||
|
|
||
| # Reference-level explanation |
There was a problem hiding this comment.
The content in this section seems more like statutes, rather than an "explanation". It's basicly rules, so I'd adapt the title accordingly.
|
|
||
| Another important goal of these changes is to create welcoming entry points for the community to subscribe to bodies of work and research. These entry points are curated by the Teams and Working Groups themselves. These Teams and Working Groups should serve the purpose of encouraging new users, engaging with them and enabling contribution as simply as possible. | ||
|
|
||
| # Guide-level explanation |
There was a problem hiding this comment.
I don't fully understand what guide-level explanation means as a term at first sight. High-level overview? or simply Overview?
|
Ops, I looked into this without having seen #1 and realizing this is following an RFC template. It's weird because the "proposal to get governance structure" contains the implementation of it in the same document. I guess the final Governance document should be separate from the RFC. In any case, take my comments in this light. |
| - What does success look like? If this Team or WG achieves its goals, what will the results be? | ||
| - Which other Teams and WGs will this group primarily interact with? Why? Have they expressed a need for it to exist? | ||
|
|
||
| ### 2. Proposal (RFC) |
There was a problem hiding this comment.
@flyingzumwalt I want to propose a libp2p Team, initially consisting of myself and Cole Brown. I also want to propose a libp2p Working Group consisting of the team as well as others who are part-time involved in libp2p development (like @vyzo or @Stebalien or @whyrusleeping or @diasdavid).
A couple problems I see:
- It seems weird that the libp2p team and WG's RFCs would be under the IPFS org, since we want libp2p to be an independent project at the same level as IPFS.
- There are not technically two Teams requesting a libp2p Working Group. I'm bending the definitions a little to allow libp2p to have a "Team" (in the sense of this RFC) and an "Extended Team" (a concept not addressed in this document but referring to a broader group of people with involvement in libp2p.
Thoughts on how I should approach this? Maybe libp2p is exceptional because it is trying to become its own project at the same level as IPFS. But I wonder how exceptional that really is.
There was a problem hiding this comment.
There are not technically two Teams requesting a libp2p Working Group
It would not be difficult to extract a request for a libp2p WG from go-ipfs Team, Cluster team, libp2p team, js-ipfs team and maybe some other, if you ask nicely :)
There was a problem hiding this comment.
i think that's just premature; i don't think it's wise having two newbies in the project running on their own.
Let bigs get acquainted with the codebase first.
| In order to complete the formation of the Team/WG, in addition to getting members to sign on and allocate time, you must also: | ||
|
|
||
| 1. Create a landing page for the group that lists its purpose, audiences, members, responsibilities, products and services. (This is often a landing page on a github repository dedicated to the group or its main product/service) | ||
| 2. Add the group to the **[TODO] Full list of Teams and WGs**, grouped according to primary funnel |
There was a problem hiding this comment.
[TODO] Full list of Teams and WGs
Where will this doc be located?
| - Teams write higher-level OKRs that condense and summarize their OKRs so they can be | ||
| to percolated upwards | ||
| - Define how membership of Core WG will be updated over time | ||
| - One leading approach is for the captains of all top-level Teams to be automatically on the Core Working Group, but this runs a risk of the group getting too big when we form more Teams and Working Groups. |
There was a problem hiding this comment.
It should be fine as long we limit it to one person per WG (and ignore Teams).
| - Note: In Rust, the leader of a WG must be part of the core team | ||
| - [ ] Define: How do OKRs percolate up from sub-teams? | ||
| - Some options: | ||
| - The objectives percolate up, becoming KRs in their parent group's OKRs list |
There was a problem hiding this comment.
I suspect it will be quite tricky to convert every child's Objective into a parent's KR. In my mind these are fundamentally different things and requirement for such systemic translation may introduce duplication and unnecessary overhead to the entire process. Not saying it can't be done, but the process will be lossy and fuzzy with unknown value added.
Personally I'd go with a rule of thumb stating there should be no "OKR translation"
(a Team writes OKRs that could be copied&pasted to WG sheet as-is).
There was a problem hiding this comment.
My understanding of OKRs was that they are defined top-down, see https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/develop-team-OKRs/ also contains a discussion regarding the below bullet point on OKRs at leaves.
| [drawbacks]: #drawbacks | ||
|
|
||
| Why should we *not* do this? | ||
| - If we don't set the right protocols for creation & dissolution of working groups, we will end up with a lot of confusion about who is responsible for what, meaning balls will get dropped, people will get frustrated, and productive time will be wasted. |
There was a problem hiding this comment.
I may be reading this wrong, but this just seems like another reason why we should do this?
There was a problem hiding this comment.
"Why shouldnt you jump off this cliff?"
"If you don't jump off this cliff, you won't experience the amazing feeling of freefall!"
| ### 1. Design | ||
|
|
||
| Anyone can propose creating a Team or Working Group. In order to be considered, it must satisfy a number of basic conditions: | ||
| - A _Team_ **must have at least 2 people** whose **Full Time** efforts are primarily focused on that Team's work. |
There was a problem hiding this comment.
Is this the third time this is stated in this document? It would be great if this whole thing was much smaller and got to the point sooner.
Proposes a governance structure with protocols for creating & dissolving working groups, using RFCs, etc.