I have come to the conclusion that designers can demand the same kind of participation in this project as anybody else. That entails opportunity to participate by creating consensus among peers from the same domain. No coder has to create consensus among designers in code matters. I demand the same thing for designers. If FreedomBox wants to grow and diversify its community, it needs to offer more ways to contribute outside the established circles which formed around its initial code aspect.
We need to start discussing how different parts of the project interact, what they consist of, what their boundaries are. A better RFC process adds extra value in general (which is why I do support it), but does not replace a needed structural change.
What would be the process of deciding “peers from the same domain”. How will contributors get assigned to a particular domain? Any such process will introduce an extra entry barrier to new contributors.
Anyone in the project irrespective of the area they are contributing to may comment on code merge requests. We had translators comment on code about how internationalized messages should be.
FreedomBox wants to grow and diversify its community. Having a process for cordoning off people into domains and not allowing them to contribute across domains will offer less ways to contribute and not more.
Our community needs to decide on what different domains make sense to have. I can see lots of different ways to add a new structure. The simplest (from my personal perspective) would be “Design” & “Code”, but I think it might make sense to think about domains like “Public Relations”, “Moderators”, “Translation”, “UX”, “UI”, … all subject to a more detailed description what that exactly entails. Assigning contributors would work just like it works now with the one domain that we currently have. I don’t see an extra barrier, we would be exchanging one catch-all barrier with multiple, but more fitting ones. Designers would not be crutial to “on-boarding” coders and the other way round, too.
Comments would always remain welcome of course, but final consensus would have to be created among everybody from the respective area only.
My understanding is that a coder in a position you describe would welcome comments as valuable feedback, but not necessarily as a new partner in finding consensus on how coding should happen.
If there is a justifiable overlap of interests, the entire community needs to find a solution, just like it would happen now.
This process does not suppress contributions! – to the contrary: contributions withstand only the scrutiny of the relevant part of the community, not everybody. Anybody could fill multiple community roles, too.
Growth and diversity need more different contributors. Not contributions to more different areas.
On the most recent progress call, we agreed to adopt an enhanced RFC procedure. We don’t need to adopt the same RFC procedure that I proposed on this thread, but we will be adoting some RFC procudure, to be determined later. It is a sign of progress that we all agreed to at least doing this much.
The design question
Next, we need to figure out how design is governed in the project. On the most recent progress call, nobody explicitly expressed support for @mray’s proposal of roles and domains, but people did sympathize with his concern. So that leaves us with the question of how design is governed on our project.
Some people had ideas on the most recent progress call, like following the example of Gnome. I encourage people to share their ideas in this thread.
An important point brought up by @jvalleroy during the previous meeting was experimenting with ideas. Building on that, I propose:
We ensure that all implementations, plans or designs are kept open to changes after acceptance. This means that if something has been implemented in code or accepted as a design/plan it can still be modified later with more proposals as long as those are also accepted. This allows achieving consensus on a proposal much easier:
We can agree to treat the proposal not as permanent but also as an experiment. A proposal can get accepted just to see how it works and receive feedback.
We don’t have to consider all the very long term problems with a proposal given that the proposal, or implementation based on it, can be changed later.
Minor tweaks to a proposal can be made later instead of ironing out all details upfront.
Some obvious considerations when this approach will work:
The changes due to re-implementation at a later time are not of very high effort.
Backward compatibility should not be broken for end users or simple path of upgrade exists for user with each change.
@sunil, just to make sure I’m understanding you correctly, is this an accurate restatement of your proposal?
We adopt an enhanced RFC procedure which includes some of the features previously mentioned in this thread (e.g. list of action items, time limit for discussion)
One component of our RFC procedure should be the right to revise proposals AFTER they have been accepted OR implemented. Revision is subject to the same discussion as the original proposal and can’t be done without the community’s consensus. But it is hoped that revision can be taken up whenever an accepted proposal is found to have some flaws.
The purpose of building a “right to revise” into our RFC procedure is to uphold the spirit of experimentation and foster incremental improvements to our software. It should be easy to improve imperfect proposals, and the right to revise aims to make it easy.
If that is what you have in mind, I support your proposal. But one thing which I think will be important is the acceptance of revisions. I don’t think anyone should have the power to unilaterally revise accepted proposals (and I don’t think that is what you are proposing). I think revisions should be subject to discussion among relevant parties.
Yes, the RFC process simply acknowledges that an idea, proposal or implementation can be changed later.
Yes but not just in case of flaws, but also for any other reason (such as that the original RFC was incomplete or was meant for experimentation which has ended and yielded outcome).
Yes. And another important purpose is to allow easier acceptance of all RFC because problems and objections can always be rectified later.
My plan did not propose or intend unilateral revision.
One clear outcome of this approach is that we don’t reject proposals just because something contradicting was accepted earlier. Every proposal stands on its own merit and will provide reasons for the necessity of change.
We seem to cover different topics now: A page on our website, our RFC process and community structure. This makes it hard to follow and reply. I propose to create separate topics. (I think discourse allows to branch them somehow)
Yes, it does seem like we are having different discussions in parallel. I think the RFC matter is just about complete, and the text for our website is a topic we can return to once all discussions are complete. If you want to create a separate thread for community structure, please do. It sounds like a good way to restart that discussion with fresh eyes.