Governance in the React Native Community

[kelset]

Introduction

This conversations wants, in synergy with #41, to try starting a "second phase" of the React Native Community "renaissance". The first phase kicked off with the Lean Core effort, and culminated in react-native-community/discussions-and-proposals#63.

Over the last 6 months, we are seeing how that "stuck the landing" and the challenges that have surfaced since.

The core of it

The React Native Community organisation, for historical reasons, never had a clear governance model.

This led to a series of issues, most of which are well described in "The tyranny of structurelessness":

As long as the structure of the group is informal, the rules of how decisions are made are known only to a few and awareness of power is limited to those who know the rules. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware.

In our precise scenario, there is also to keep in mind that most of us are core contributors and maintainers in voluntary form, during our free time: it's understandable that to add, on top of this, the task of being part of a decision making process could be something that some people simply don't want to be involved with.

We have been trying to work around this structurelessness in the past few months, and more than a few issues in this very repository are attempts to discuss guidelines that every maintainer can follow.

Moreover, via repositories like this that can rollover health files (#3), by introducing bots (#30), having a template when generating new repo, a CLI to simplify targeting platforms (https://github.com/react-native-community/bob) and a CircleCI Orb to provide an easy start for CI we have been trying to support each other and reduce the amount of "overheard" that supporting a RN library can have.

We have also took care some long overdue "chores":

• we finally have a rough 'map' of who-is-maintaining-what (check maintainers.md)
• every maintainer is a member of the repo (Organisation updates - PLEASE READ ❤️ #40), and part of the @react-native-community/maintainers team
• we have an active twitter account (@ReactNativeComm)
• and an official rncomm email account (up to a few months ago, the org was still attached to the personal email of an old maintainer not active in RN anymore)

But still, without any clear governance, it's usually up to the person who kicks off a discussion to transform it into something actionable; and in more than a few cases, given the low response, these conversation end up staling up and no action is taken on them (for example: #34).

We should try to change that - to quote The tyranny of structurelessness again:

For everyone to have the opportunity to be involved in a given group and to participate in its activities the structure must be explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized.

The big question

What would be a governance model for this organisation that, while keeping a lean structure, would not make members feel forced into decisions?

Discussion points & potential solutions

I don't have a precise idea of what would be the best approach here: if a few people were responsible for taking those decision, it would surely remove the burden from every maintainers to keep up with all the conversations and comment on them (and, honestly, most of them already don't - as mentioned a few times already).

But at the same time, it may lead to scenarios where some maintainers would feel left out / not feel heard.

To mention The tyranny of structurelessness once more, I think that the principles described in the last section are something we should try to keep in mind.

Another interesting idea I've read, when it comes to instead a flat governance approach, is the one described by Roman Imankulo, used at Doist:

Rough consensus isn’t majority rule. It’s okay to go ahead with a solution that may not look like the best choice for everyone or even the majority. “Not the best choice” means that you believe there is a better way to solve the problem, but you accept that this one will work too. That type of feedback should be welcomed, but it shouldn’t be allowed to slow down a decision.

But of course I'm sure there is plenty of other options - among which:

/tinfoil hat section

Way out there - and, again, WAY OUT THERE - there is also a possibility for this problem to be connected to #41, as proposed by Harry Tormey:

I think the key to organizational support is aligning interests between the community and the organizations. Perhaps a voting system with tiered recurring donations? I.e if company x donates y $ they can vote on prioritizing bugs.

This is an approach used in some foundations and organisations, and I first actually heard about it when discussing the release process for the main React Native; I can't remember precisely where, but I'm sure it was something that was considered when trying to think for different alternatives for the cherry-pick/release patches process - given the line in the sand that the FB team has on this topic.

But, again, this is just to throw some more ideas at the wall to sparks conversations.

/end tinfoil hat section

---

This is all I could think of on this subject. I probably forgot some things worth mentioning. Please contribute to this conversation, share your experience! I'd love to hear different opinions and more ideas on the matter!

[mikehardy]

I think the key to organizational support is aligning interests between the community and the organizations. Perhaps a voting system with tiered recurring donations? I.e if company x donates y $ they can vote on prioritizing bugs.

In my house we call that "implementor's choice". It's connected to effort not money. Connected with the idea that a "good enough" solution may proceed (sometimes, and with sensitivity), then if you're doing the work - carry on. There is a sub-text there also which is that generally the bike-shedding of non-implementors that were obstructing the progress of the implementor are actually sort of Dunning-Kruger, i.e. if they were implementing they'd usually work through most of the same issues and be right to the plan they were nit-picking earlier.

The TL;DR: if you're putting in a lot effort (as an org or a contributor) you get to make some tough (possibly non-majority) calls. But explicitness and transparency and ability to gather that clout (and have it dissipate) is important if you go down that path, so that it's open

And in general having voting windows and polls isn't awful. If you're interested participate and we'll make a decision, if you can't be bothered ... plurality vs majority

[brentvatne]

An update on this front: representatives from React Native partner organizations and Facebook have voted unanimously in favour of a majority voting model for making decisions that "meaningfully change the react-native-community organization". The topic we're moving on to discussing now will be "What packages belong in react-native-community?" (react-native-community/discussions-and-proposals#176). You can expect to see some updates on that shortly.