RFC: Community Governance Page

[haidar]

This thread is for discussing the creation of a set of guidelines for our community governance.

A comment in preface: Throughout this process, we’ll be setting standards which will be foundational for our community. I therefore encourage everyone in the core team to participate in this thread.

I’m following up on our discussion from our most recent progress call. One of the items on our to-do list is clarifying our community governance. On the call, we agreed to try to learn from Mozilla’s governance guidelines.

Instead of lumping this stuff in with the CoC, I propose that we create a page on freedombox.org at /governance which lists the members of our core team and explains how the community governs itself. Listing the core devs on a web page is fairly standard for most FOSS projects, and I think we especially need to do it now that we are getting more attention from bloggers and journalists. People will be legitimately curious about how our software is produced.

Based on my judgment and the Mozilla checklist, I think our governance page should have three sections: (1) description of our community governance, (2) Team Members (and their roles), and (3) Decision Making (which explains cycles of feedback).

1. Description of our community governance:

At the top of the page, we should write a brief description about how our community creates software. To most of the world, it is an inexplicable miracle that volunteers could create a software system. In my opinion, the description should convey to the world that (1) our team works collaboratively and (2) our production process is reliable (i.e. we’ve built a reliable ecosystem which is more than just a few people with keyboards). My proposal for this description is as follows:

The FreedomBox software project is produced by a team of contributors—some volunteers, some full-time developers—who govern the community together. In governance, we rely on mutually enforced standards, not externally enforced rules. The community aims to make decisions using consensus that emerges from open discussion. In cases of disagreement, the community discusses until a resolution has been found or agrees to postpone the discussion. Though a select number of our developers have the power to accept merge requests, anyone is welcome to join our contributor community and submit code or non-code contributions.

Feedback on this description is strongly encouraged.

2. Clarifying our leadership and our respective roles:

Problem: For newcomers and existing contributors alike, it isn’t always easy to figure out who does what, and who doesn’t do what in our project. And even our contributors may feel a bit disempowered by the lack of formal recognition for their roles in the project, because it is hard to figure out the boundaries of your own authority when nobody’s role is well understood.

Proposal: We should have a section of our governance page (under the heading “Team”) which lists the names or aliases of each core team member. Here, we should list each person’s respective role. Maybe terms like Developer, Maintainer, and Designer could be used, and I think we should affix some of those titles with words like “Lead” in cases where it is relevant. I think we should also list a brief list of responsibilities beneath each person (2 or 3 bullet points). And people should also feel free to list their preferred gender pronouns if they want.

What do people think of this?

3. Clarifying our decision making and cycles of feedback:

The problem: sometimes, ideas go through endless cycles of feedback, and this results in undue delays. For example, @mray’s proposed relaunch of freedombox.org has been almost ready to publish for months. And it looks great to me. But momentum has been lost. I know we can do better—and I think a feedback cycle is a good place to start. The way we handled feedback for the reachability wizard was efficient, in my opinion. And I think we should hold ourselves to that same standard of efficiency more often.

Proposal: We should set standards for cycles of feedback that look something this:

Many of the decisions made by our team are uncontroversial and don’t require extended periods of discussion and feedback. But sometimes, extended periods of discussion and feedback are necessary parts of our decision-making process. In such cases, we use Requests for Comments. For tasks that are bigger than average and/or could plausibly be subject to disagreement, the proposer should open a Request for Comments (RFC) on our Gitlab page. The RFC written by a proposer should include (1) a sketch, mock-up, or written description of the task, (2) a brief explanation of the task’s importance, (3) a general list of action items required to execute the task, and (4) estimated timelines for both the RFC discussion period and implementation period. RFC’s should be open for no less than one week and no longer than one month. If, after one month, consensus has not yet emerged, the RFC can be extended for an additional month, but there must be concrete reasons stated for extending the RFC.

In my opinion, our RFC’s sometimes adhere to this description already—the only thing we need to do better is maintaining reasonable timelines.

Conclusion:

Those are my three priorities for our governance page.

1. What do people think of these proposals?

2. What would you want to see on a governance page?

[haidar]

Tagging @jvalleroy @mray @njoseph @sunil

[mray]

@haidar

Instead of lumping this stuff in with the CoC, I propose that we create a page on freedombox.org at /governance

…

Conclusion:

Those are my three priorities for our governance page.

1. What do people think of these proposals?
2. What would you want to see on a governance page?

I like the idea to keep those things separate and have a dedicated online resource, but would propose to postpone discussing details until after we agree on the content of a governance page. Where and how to put things should not be a concern for us at this time.

@haidar

1. Description of our community governance

The FreedomBox software project is produced by a team of contributors—some volunteers, some full-time developers—who govern the community together. In governance, we rely on mutually enforced standards, not externally enforced rules. The community aims to make decisions using consensus that emerges from open discussion. In cases of disagreement, the community discusses until a resolution has been found or agrees to postpone the discussion. Though a select number of our developers have the power to accept merge requests, anyone is welcome to join our contributor community and submit code or non-code contributions.

I have two fundamental issues with this approach that seems to correctly describe the status quo:

1. power is bound to accepting git merge requests, putting contributors without coding background in a very unbalanced position in that process. Power should not be bound to such a technical skill, but to the result of a more general decision making process that entails domains and roles.
2. Finding consensus among the entire community does not reflect technically diverse domains of our project (e.g Code, Design, Translation, Press, …) Consensus among all people filling different roles may be too broad. Consensus among people in the same domain should suffice unless there is a noticeable impact on other domains.

I’m basically proposing a governance structure like we have it on Snowdrift.

@haidar

2. Clarifying our leadership and our respective roles:

Problem : For newcomers and existing contributors alike, it isn’t always easy to figure out who does what, and who doesn’t do what in our project. And even our contributors may feel a bit disempowered by the lack of formal recognition for their roles in the project, because it is hard to figure out the boundaries of your own authority when nobody’s role is well understood.

Proposal : We should have a section of our governance page (under the heading “Team”) which lists the names or aliases of each core team member. Here, we should list each person’s respective role. Maybe terms like Developer, Maintainer, and Designer could be used, and I think we should affix some of those titles with words like “Lead” in cases where it is relevant. I think we should also list a brief list of responsibilities beneath each person (2 or 3 bullet points). And people should also feel free to list their preferred gender pronouns if they want.

I support that proposal completely. Roles and accountabilities should be mentioned publicly after they are assigned.

@haidar

3. Clarifying our decision making and cycles of feedback:

Many of the decisions made by our team are uncontroversial and don’t require extended periods of discussion and feedback. But sometimes, extended periods of discussion and feedback are necessary parts of our decision-making process. In such cases, we use Requests for Comments. For tasks that are bigger than average and/or could plausibly be subject to disagreement, the proposer should open a Request for Comments (RFC) on our Gitlab page. The RFC written by a proposer should include (1) a sketch, mock-up, or written description of the task, (2) a brief explanation of the task’s importance, (3) a general list of action items required to execute the task, and (4) estimated timelines for both the RFC discussion period and implementation period. RFC’s should be open for no less than one week and no longer than one month. If, after one month, consensus has not yet emerged, the RFC can be extended for an additional month, but there must be concrete reasons stated for extending the RFC.

Having the concept of domains in mind, I think decision making and cycles of feedback should be defined by people filling the roles of a specific domain. One way does not necessarily have to be the only way throughout the entire project.

What would be missing here is a defined workflow among domains, though. We would need to have agreement on how development happens in general. (I’m particularly interested in the arrangement of design/ui and the creation of code that implements design and UI changes.)

But we currently lack a breakdown of our project into roles, similar to how Snowdrift.coop does.

So what I would propose is to:

1. come up with domains and roles that make sense for FreedomBox
2. agree on a workflow among domains
3. assign roles to people

[haidar]

@mray

So what I would propose is to:

1. come up with domains and roles that make sense for FreedomBox
2. agree on a workflow among domains
3. assign roles to people

Numbers 1 and 3 seem straightforward to me, and I wouldn’t oppose doing them.

Number 2 is the tough one. I think that our workflow among domains is generally free flowing because a lot of people work in multiple domains. If people are allowed to be in multiple domains (e.g. development and design), I would support defining a workflow among domains.

Last thing I want to say about all of this: I support a simple approach to your three proposals. I think we should be concise about our domains–the fewer, the better.

What do others think?

[njoseph]

I will try to keep this relevant to the governance discussion and not turn it into a retrospective discussion which we can do separately.

Roles and Titles:

Role - one person can play many
Title - many people can hold one

Each Title has many Roles

We can assign titles to people and assign roles to the titles, such that one person can unambiguously have a single title, but have multiple roles assigned to the title.
A person might choose to execute only a select set of responsibilities afforded to them by their title. This should be okay since we’ll have other people with the same title who can complement their work.

Pros:

1. Acknowledgement for contributions
2. Make it publicly known who is responsible for what, allowing new contributors to seek help from the right person

Cons:

1. In a volunteer-driven project, expecting people to perform the duties of their role on a regular basis can be a problem.
2. Roles might restrict people into not participating in work outside of their role, where their contribution might be useful.

My Opinions:

I believe that a consensus-based approach is better than a power-based one. In most healthy communities, the leader usually has to invoke their power only in extreme cases like resolving disputes. Leading without a title is usually a better approach in my opinion. A leader frequently using their power to get things done should be considered ineffective.

There are a variety of governance models ranging from BDFL to the coop models of one person, one vote.

Domains:

The FreedomBox project is composed of many interacting components, requiring a wide variety of skills from contributors. Not everyone might have the skills to make decisions in every area.
We can have formal or informal recognition of domain expertise.

If we take the approach of having domain leaders instead of or in addition to a project leader, the domain leader still should have a few restrictions on their power:

1. They cannot use their power to veto the community’s opinion and integrate something widely considered an anti-feature.
2. Power should not be used to cover up for own incompetence or for shifting the blame to someone else.

Dividing the project into domains might lead to knowledge silos, communication problems and avoidable disputes. Domains and domain leaders seems like a bad idea at this point. A project as large as Debian didn’t need them, do we?

At the same time, we should strongly consider the recommendations of someone who is an expert in the domain.

---

Feedback on @haidar’s initial proposal:

1. Description of our community governance:

The write up looks good to me.

2. Clarifying our leadership and our respective roles:

I agree with the proposal overall. Adding gender pronouns in the profile page is a good idea too.

3. Clarifying our decision making and cycles of feedback:

I think our current feedback cycle looks like this:

RFC/merge-request → feedback → action on feedback → further feedback → action … → approval

We can do better on bringing RFCs/merge requests to closure in a reasonable amount of time. Having well-defined timelines seems like a good idea. We can also add the possibility of postponing till a prerequisite dependency is met.

Disputed/controversial proposals might pose a challenge in meeting the expected timelines. Proposals should be identified and labeled as disputed as soon as possible, and put through the arbitration process (TBD).

[haidar]

@njoseph

My Opinions:

I believe that a consensus-based approach is better than a power-based one. In most healthy communities, the leader usually has to invoke their power only in extreme cases like resolving disputes. Leading without a title is usually a better approach in my opinion. A leader frequently using their power to get things done should be considered ineffective.

I agree with Joseph on this.

Currently, we have a consensus-based system. And it is flawed: we have imperfect processes for (1) reviewing proposals, (2) making it clear which parts of a proposal have been accepted/rejected, and (3) doing (1) and (2) in a timely manner.

In my opinion, our options are to either strengthen our consensus-based system or supplement it with something which is not consensus-based.

I prefer the former: we should strengthen our consensus-based system by creating a process which holds everyone more accountable to the discussion and decision-making steps. Distributing power might work for other communities, like Snowdrift, but I don’t think it fits FreedomBox. The culture of our project is one of consensus–I would rather find ways to improve our culture than ask everyone to transition to a role-based culture.

And @mray, even though we may disagree about implementation, I think we both want the same outcome: we both want our decision-making process to be improved, and we both want to prevent situations in which contributors feel disempowered. We may have different approaches, but I hope you see that you and I are reaching for the same goals.

@njoseph

We can do better on bringing RFCs/merge requests to closure in a reasonable amount of time. Having well-defined timelines seems like a good idea. We can also add the possibility of postponing till a prerequisite dependency is met.

Disputed/controversial proposals might pose a challenge in meeting the expected timelines. Proposals should be identified and labeled as disputed as soon as possible, and put through the arbitration process (TBD).

I agree with Joseph on this.

But I also think we should learn more about the arbitration process. @sunil, I’d love to learn more about what you had in mind when you proposed this.

[mray]

@njoseph

I believe that a consensus-based approach is better than a power-based one.

Maybe there was a miscommunication. Because I don’t think this is a “consensus -vs.- power” question. What I propose is a basic form of Sociocracy. Consensus is the essential part. The power should only come from the consensus that some people have some power by default, to make them work more effective in their domain. That power isn’t unchallenged, the community can withdraw power from parties misusing it.

@njoseph

RFC/merge-request → feedback → action on feedback → further feedback → action … → approval

We can do better on bringing RFCs/merge requests to closure in a reasonable amount of time. Having well-defined timelines seems like a good idea. We can also add the possibility of postponing till a prerequisite dependency is met.

Time is the least of my problems with the process. I’m trying to point out that this entire construct is built around the tools and needs of code creation – setting back other kinds of participation. I agree with optimizing the process as you propose, just be aware that this is not my problem. I’m concerned about personal questions in the process: when should feedback trigger an action? who approves?

These are the questions that don’t only need quicker answer, but answer at all. I don’t commit code, I don’t merge commits. Where does that put me in that process?

I don’t want to every single bit I do to be approved by the entire community, constantly. Imagine being a coder in an art project that decides on consensus among everybody. You’d want to be approved as the projects coder, and therefore your contribution in general, if your work is good and approving among coding peers. You’d not like to have every commit approved by everybody, running the risk that people comment on insignificant or irrelevant issues, which in turn creates feedback that you need to “act” upon. And even if you do, the code only compiles when some artist swings that magically colored brush anyway…

< /rant>

@njoseph

Domains and domain leaders seems like a bad idea at this point. A project as large as Debian didn’t need them, do we?

Looking at the output of the Debian design team makes me doubt Debian is making good choices here. A project of this proportion suffering from such bad representation is remarkable achievement in my eyes. I agree that regarding its code this may be different, but we add to Debian what itself is missing; and that’s not more command line input options…

[njoseph]

This entire message is specifically about design. Not in general about governance.

Our merge request workflows

Our primary collaborative work tool is a code forge (GitLab) which is built around a version control system (git). Neither is meant to be used for collaboration over design. I’ve heard that some enterprise project teams use design review tools. Maybe we should find a free software one.

Accepting merge requests in FreedomBox requires advanced skills in git, which we cannot expect every developer to have. This shouldn’t stop designers from reviewing the UX or UI aspects. We have tried to post screenshots whenever a new view is added. Ideally there should be an staging server on which designers, UI developers, QAs and other stakeholders should be able to interactively review UI changes. I did this setup earlier in projects with trunk-based development (where everyone directly pushes into master) but it is not as straightforward to do in our pull request model.

@mray You are not really obligated to merge the pull requests yourself. You can give your approval and ask one of the maintainers to merge it. We have been using the WIP: suffix to show that a merge request is still in review. Maybe we can have a design-approved label to indicate that design is reviewed and found satisfactory for a merge request.

On being a designer in a development team

To comment on a programmer’s work, you have to be a programmer yourself. To comment on a translator’s work, you have to have knowledge of the two languages too. But to comment on a designer’s work, you just have to be able to see it. The bar is just too low. This is a common complaint of designers working with development teams. A designer has to explain their decisions to people who are not designers themselves but have an opinion anyway, on how things should look like.

A programmer will not change their algorithm just because an artist on the team doesn’t like its flowchart. They will defend their algorithm on facts like performance, resource usage etc. A designer should defend aspects of their design too. However, functional requirements should still be negotiable (e.g. whether to put an Edward Snowden quote or Eben Moglen quote on our home page) whether in design or development.

Design reviews?

Come to think of it, we’ve never done real design reviews. All of our reviews have been of the UI implementations of the designs. Commenting on a design so late in the process is frustrating for everyone. We should reach a consensus at the mockup stage itself and stick to the design in implementation, whoever implements it. Any reviews of the implementations are code reviews in the usual GitLab merge request workflow. Missing pieces of the original design should be treated as unsatisfied requirements and deviations from it as bugs.

None of our current core developers is primarily a UI developer, which is causing delays in implementations of designs. This also leads to design reviews being ignored and problems raised at implementation stage.

BTW, I don’t even know if someone like me is qualified to be doing design reviews, other than saying things like “this won’t look good on mobile” etc.

In our current state, having a domain for design will make it a team of one with nobody else to even do a review. A design BDFL?
Will this domain also include future UI developers who might join, or is it only for designers?

[mray]

@haidar

The culture of our project is one of consensus–I would rather find ways to improve our culture than ask everyone to transition to a role-based culture.

And @mray, even though we may disagree about implementation, I think we both want the same outcome: we both want our decision-making process to be improved, and we both want to prevent situations in which contributors feel disempowered. We may have different approaches, but I hope you see that you and I are reaching for the same goals.

I generally feel misrepresented when consensus is seen as an alternative to what I propose.
“role-based” culture just entirely misses my point. If there were only two domains “code” and “design” nothing would change on how code gets created. It would change how design gets created, though. This isn’t adding anything but one hierarchical division, per domain.

There are different areas of skills and expertise – coding does not cover all of them, obviously.

As a designer I come from another domain and ask basically for the same kind of consensus that coders are free to form in their domain right now. This isn’t about optimizing established processes, but about broadening the scope of the entire project. Nobody wants to build consensus in a community that mainly isn’t from your domain. Coders don’t want commits to be approved by non-coders – and fortunately they don’t have to!! That’s great for them! And that is great for the project. I don’t have that privilege at all. But the reverse should be true, too: non-coders should not get approved by coders (unless we speak of the code implementation itself). When a project aims to include new domains, I believe we can’t just to code developed and try to optimize for more.

I’m the only designer and can only vouch for my domain here, maybe there are others, maybe it is the only other – I don’t know. We need to make sure that non-coding contributions have their proper place, too.

@haidar I’m certain we all are fighting for the same outcome/goals, but I’m here to say that it isn’t (only) because we are handling our current process poorly, the process itself is problematic for… me as a designer.

[mray]

@njoseph

In our current state, having a domain for design will make it a team of one with nobody else to even do a review. A design BDFL?

More of a BDFALATCA – Benevolent Dictator For As Long As The Community Approves, and only as long as there is nobody else in a design role, too. Not happy about that? Get more designers on board.

@njoseph

Will this domain also include future UI developers who might join, or is it only for designers?

You ask which domains need to be established? What roles they can hold is up for discussion? – I’m open to how peoples ideas of UI / UX / Design / Marketing /… diverge, I just know I’m not a coder or kernel hacker of some sort, and so are many other (potential) contributors. Of course the idea is to embrace new contributors that are a fit for our project or want to be.

[haidar]

@mray

Because I don’t think this is a “consensus -vs.- power” question. What I propose is a basic form of Sociocracy. Consensus is the essential part. The power should only come from the consensus that some people have some power by default, to make them work more effective in their domain.

So far, there hasn’t been consensus over the idea that some people should be formally given some power by default. Without consensus about that, the role-based proposal cannot be described as consensus-based.

@njoseph

Maybe we can have a design-approved label to indicate that design is reviewed and found satisfactory for a merge request.

I like that idea.

@njoseph

Design reviews?

Come to think of it, we’ve never done real design reviews. All of our reviews have been of the UI implementations of the designs. Commenting on a design so late in the process is frustrating for everyone. We should reach a consensus at the mockup stage itself and stick to the design in implementation, whoever implements it.

I agree that we should have design reviews. We can use an RFC process for mockups early in the process.

@mray

But the reverse should be true, too: non-coders should not get approved by coders (unless we speak of the code implementation itself).

I think back to what Joseph said about functional requirements being negotiable. I think it is good to give the coders a voice on some design matters.

Ultimately, I support strengthening our consensus-based approach because I think we can rely on ourselves to have a better culture around design in the future. I don’t think we need to give special authority to a Design role because I still have faith in our community’s ability to hold itself accountable. We can still trust each other enough to rely on community-enforced standards instead of pre-defined roles which formally divide authority. I think we can still rely on each other to make good faith efforts to collaborate constructively.

We should at least try to improve our current system before we move on to a role-based division of power.

[njoseph]

Found a timely and relevant document from the Loomio team.
We might be implicitly following most of it already. But I like how it is spelled out in this document.

Patterns for Decentralized Organizing

8246de_248a47ddbd3c4d209667ff5508ee300b.pdf

[jvalleroy]

Regarding RFCs, should we try to more formally document the decisions arrived at by consensus? In some cases there is agreement of the broad scope of the RFC, but no clear consensus on the details. For an RFC with many comments, it may not be clear which decisions were arrived at.

[haidar]

@jvalleroy

Regarding RFCs, should we try to more formally document the decisions arrived at by consensus? In some cases there is agreement of the broad scope of the RFC, but no clear consensus on the details. For an RFC with many comments, it may not be clear which decisions were arrived at.

Yes, I strongly support this idea. I think this resolves our main problem in the RFC process.

Perhaps we can add something like this to the governance page:

In some cases, an RFC centers on a big project. For an RFC of this kind, there may be many comments, and it may not be clear which decisions were arrived at. When there is agreement on the idea in general but no clear consensus on the details, participants should put in writing at the conclusion of the RFC what decisions were made and which parts of the proposal were accepted.

How does that sound?

[haidar]

@njoseph

Found a timely and relevant document from the Loomio team.

Thanks for sharing, Joseph.

Here is a highlight from that document which I think others should see:

3. Make explicit norms and boundaries
   Norms = how we do things around here. Boundaries = what we don’t do
   around here. Many groups leave these things unsaid, relying on “common
   sense”.
   Challenge:
   Conflicts grow when people have different unspoken assumptions (everyone
   has different common sense). When you cross an invisible boundary, it takes
   huge energy to make the boundary explicit, before you can get to the
   behaviour.

In my opinion, that is exactly what we are trying to do here: make our norms explicit.

[mray]

@haidar

Maybe we can have a design-approved label to indicate that design is reviewed and found satisfactory for a merge request.

I like that idea.

Might be a handy shortcut, but it would still be begging the question when a label would be necessary in the first place.

@haidar

So far, there hasn’t been consensus over the idea that some people should be formally given some power by default. Without consensus about that, the role-based proposal cannot be described as consensus-based.

I don’t follow. Some people already do have power by default (like access to the repository or general infrastructure). If not by consensus, how did they get it? I feel like I’m not getting an important point here.

@haidar

We can use an RFC process for mockups early in the process.

Can you please explain the role of comments in an RFC process to me? I never worked on standards and don’t see how comments help decisions.

(edit:)

I do know how they help decisions of course but wonder what their direct impact is – like is there a certain threshold of supporting comments needed?

[haidar]

@mray

So far, there hasn’t been consensus over the idea that some people should be formally given some power by default. Without consensus about that, the role-based proposal cannot be described as consensus-based.

I don’t follow. Some people already do have power by default (like access to the repository or general infrastructure). If not by consensus, how did they get it? I feel like I’m not getting an important point here.

I meant that there hasn’t been consensus over the proposal to have role-based distribution of decision-making power. It wasn’t an important point, though.

@mray

Can you please explain the role of comments in an RFC process to me? I never worked on standards and don’t see how comments help decisions.

(edit:)

I do know how they help decisions of course but wonder what their direct impact is – like is there a certain threshold of supporting comments needed?

In my vision of RFC’s, I don’t see a threshold for supporting comments. The role of comments is (1) to improve the proposal with constructive criticism and (2) to give everyone a chance to contribute to the discussion.

The reason I am proposing a formalized RFC process for our community in particular is that it can help solve these problems:

1. Disagreement between parties on what decisions emerged from a discussion about a given proposal: With an RFC, the discussion process will end with a concrete statement of what decisions were made. Though people will have to make compromises, there will not be confusion about what to expect.
2. Lack of timeline on discussion and implementation: With formal guidelines for RFCs, discussions of very promising ideas won’t go on for unnecessarily long period of time. Thus, we can avoid the situation we are in with the proposed relaunch of freedombox.org.

[mray]

@haidar

In my vision of RFC’s, I don’t see a threshold for supporting comments. The role of comments is (1) to improve the proposal with constructive criticism and (2) to give everyone a chance to contribute to the discussion.

That is my understanding of comments as well. So we can agree that a clearly specified RFC process is an improvement generally, but has no impact on the issue of roles and accountability?

[mray]

@njoseph I think we do follow some parts but miss some crucial aspects in my eyes.

My most importantly we miss two parts

4. Keep talking about power:

---

I agree that power isn’t equally distributed (and should not be), we need to be transparent and discuss who has it and how is it earned. Currently there is a bad imbalance coming from a strong code bias of the project.

7. Use rhythm to balance flexibility and focus

---

Everyone being asked about everything isn’t a sensible approach when people from different backgrounds work together. We need to build up trust in other people and their decisions.

[haidar]

@mray

So we can agree that a clearly specified RFC process is an improvement generally, but has no impact on the issue of roles and accountability?

I agree that the RFC process has no impact on roles. My proposal for roles was to list each person’s respective roles on the website without distributing specific decision-making power to those roles (as discussed previously in this thread).

But the RFC process has an impact on accountability: if we formalize the RFC process in the way I propose, then participants will need to (1) hold themselves accountable to timelines for discussion and implementation and (2) be explicit about what they stand for and what decisions emerge from a discussion. RFC’s hold people accountable to a process.