mikehardy
commented
5 years ago 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
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 https://github.com/react-native-community/discussions-and-proposals/issues/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":
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":
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: https://github.com/react-native-community/.github/issues/34).
We should try to change that - to quote The tyranny of structurelessness again:
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:
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:
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!