Nobody was proposing appointing a BDFL unless I’m mistaken, so I think that was perhaps a misunderstanding. I’m sorry if this came across as a hair trigger response to you, and I understand your intention. I hope you can understand that this is a diverse community with varying backgrounds, experiences and sensitivities, and that part of making an inclusive community might mean accepting moderation for things that we might not personally find problematic. In most cases this costs us very little or nothing, and I think it has helped make this a more positive community than we have sometimes been. If you want to discuss this further I’m happy to do so off of this thread.
2 Likes
“Benevolent dictator” is not a loaded term in programming language development context. It has referred to the position of Guido van Rossum in the Python community and was used in the very-relevant-to-this-discussion essay, “Homesteading the Noosphere” by Eric S. Raymond.
page 22:
The simplest non-trivial case is when a project has multiple co-maintainers working under a single ‘benevolent dictator’ who owns the project. Custom favors this mode for group projects; it has been shown to work on projects as large as the Linux kernel or Emacs, and solves the “who decides” problem in a way that is not obviously worse than any of the alternatives.
Typically, a benevolent-dictator organization evolves from an owner-maintainer organization as the founder attracts contributors. Even if the owner stays dictator, it introduces a new level of possible disputes over who gets credited for what parts of the project.
In this situation, custom places an obligation on the owner/dictator to credit contributors fairly (through, for example, appropriate mentions in README or history files). In terms of the Lockean property model, this means that by contributing to a project you earn part of its reputation return (positive or negative).
Pursuing this logic, we see that a ‘benevolent dictator’ does not in fact own his entire project absolutely. Though he has the right to make binding decisions, he in effect trades away shares of the total reputation return in exchange for others’ work. The analogy with sharecropping on a farm is almost irresistible, except that a contributor’s name stays in the credits and continues to ‘earn’ to some degree even after that contributor is no longer active.
As benevolent-dictator projects add more participants, they tend to develop two tiers of contributors; ordinary contributors and co-developers. A typical path to becoming a co-developer is taking responsibility for a major subsystem of the project. Another is to take the role of ‘lord high fixer’, characterizing and fixing many bugs. In this way or others, co-developers are the contributors who make a substantial and continuing investment of timein the project.
1 Like
Hi James. Yes I’m aware of the concept and that text, which was quoted higher in the thread. The idea has been critiqued, and the benevolence of founders has been questioned, as I know you yourself have experienced. In any case, unless you’d like to take up the role again, I don’t think we were really talking about a BDFL. Maybe something closer to “co-developers”, but I at least would prefer if these roles involved breaking deadlocks as little as possible. My impression is that things being held up by strong disagreement is rare. Far more common is just a lack of any decision being made in low or zero risk cases, or things stalling simply because it’s unclear who has responsibility.
(On a more meta level we might reflect that we have various members saying they can’t be part of the community both because moderation is too strong and not strong enough. The impossibility of threading that needle may be part of why we have so few moderators left, but that’s a different conversation…)
1 Like
i’m not actively involved in supercollider development (yet? :)), but i’ve been contributing to other open source projects. the council structure with explicit temporary delegation looks like an interesting experiment! it may help avoid maintainer burnout as well by normalizing passing the hat on when it makes sense.
i have hit the exact described issue (not knowing how to move things forward) when contributing some features and fixes to scel. there’s quite a long list of open improvements, many of which seem to be just waiting for something to happen. would this be under the umbrella of the suggested council structure as well? i don’t see it listed explicitly.
Hopefully yes, I think!
At the Supercollider Forum roundtable discussion, @Sam_Pluta asked the participants at each table to discuss the most important issues facing the future of Supercollider… I was suprised how many of the tables settled on governance issues - perhaps half - basically echoing @dscheiba’s concerns at the top of the thread.
I think we can say now that there is a consensus to move forward on this issue! @dscheba - and all - what should be our first steps/next steps?
@Sam_Pluta @tedmoore is there any kind of summary of that session? I think it’s a great thing to do and great to do it in person (I always have the impression it’s much easier to reach consensus that way), but I know many of us who couldn’t attend are nevertheless curious.
I have notes from my table and I received another table’s over email yesterday. I’ll wait for more to come in (and if anyone reading this has a table’s notes, please send them to me over email!)
Just one detail – to declare someone responsible in the sense of a “Benevolent dictator” takes off load in two ways in situations that are hard to decide: it allows others to rely on a judgement and responsibility of a single person (instead of a deadlock and an ever growing fore and back). And it allows the benevolent dictator to just actually make a decision with full knowledge that it may be wrong (instead of backing out when it gets ambivalent).
5 Likes
Thanks for all the feedback in this thread and @semiquaver delivering the impulse to proceed here!
IMO the actual changes wouldn’t be too different from the current situation except for making implicit structures more explicit and empowering the designated people to be more “pro-active” within their assigned domain.
Therefore the next steps would be
- I try to finalize a first version of the list above by reaching out to the people and ask/verify if they agree on taking care of their proposed domain. This list would then be published as a sticky post in the dev forum.
- Afterwards, I would like to start assigning PRs according to this list. In other projects it is best practice to provide some guidance for new arrivals so the contributions grow in a sustainable manner. An assignment is not final and comes with no liabilities except to deliver a first-response within one month which can also be to simply assign it to another person.
This hopefully helps us to move some existing and future PRs out of limbo.
If there are multiple people assigned to one domain I am sure that they will find a good way to operate as a group on their own.
Please correct me if I am wrong, but I don’t have the feeling that there is a strong divergence in the alignment of users and devs - though both groups may have a different emphasis on certain topics. I also don’t have the feeling that the current proposed people would power-trip. If there are concerns about specific persons I think it would be fair to express those - if one doesn’t want to voice want to voice such a concern in public it is also possible to write me a DM and I’ll try to evaluate this with the mod team.
The problem I want to solve with this proposition is on how we can settle for a decission if there seems to be a general agreement within the community that there exists a certain problem which needs action.
Currently many decisions are postponed because nobody wants to take responsibility as nobody feels authorized to decide for the whole community.
This leads to stalemate situations where the decision is postponed indefinite which then accumulate to frustration and I have the feeling that this isn’t very healthy for this project.
I simply want to give some regular contributors with expertise “authority” to apply and merge (non-controversial) changes into the codebase, because right now everyone just waits for somebody else to do this.
1 Like
Please correct me if I am wrong, but I don’t have the feeling that there is a strong divergence in the alignment of users and devs - though both groups may have a different emphasis on certain topics. I also don’t have the feeling that the current proposed people would power-trip.
I don’t think there needs to be a concern that troublesome people are prone to “power-trip.” That, of course, is a possibility, and the probability grows over time that people become entrenched in silos. We have seen bad behavior in the past, but I don’t think that needs revisiting. The concerns I’ve mentioned are all in play even if we feel that SC devs are all basically nice, sweet people.
The problem I want to solve with this proposition is on how we can settle for a decission if there seems to be a general agreement within the community that there exists a certain problem which needs action.
Can you clarify, is the goal to solve A or B?:
A) The community agrees that there is a problem which needs action, but the community disagrees on which action to take?
B) The community just wants a solution and doesn’t particularly care how it’s solved?
My experience as an SC dev was that there were a lot more of A than B, for code that actually got held up.
If the concern is B, I think the proposal of timelines is a great way to keep things moving: “Hey, we’re about to merge this. Any objections? We’ll merge by [date in the future] if nobody has concerns.” Maybe there can be a Discourse thread for any user-facing changes? I also think the idea of organizing people into rough triage groups makes sense as a way to keep things moving.
But that doesn’t actually depend on empowering people as “benevolent deciders.” Adding a role of “the community has passionate views about multiple possibilities, so the controversial decision will be made by one person” seems like a recipe for trouble.
(Again, my 2 cents)
This sounds very good, thanks for taking an organizational role on this.
I have two suggestions here, in case you can see a way to fit them in (but also: moving forward is much more important than over-planning details 
)
- Some kind of regular cycles or check-in would be useful. This gives a chance to revisit roles, look at whether things are moving, address issues etc. This gives space for people to say e.g. “I’m a bit overloaded, so I’m way behind on X”, “I’ve got a bunch of free time this month and can take on something hard”, or “this isn’t working”. Re-establishing the regular dev meetings might be a good way to do this, or just a regular 3 month status check. This also reduces the pressure to address all governance + organizational issues at once, since there’s a dependable format for raising and addressing issues.
- From experience, it’s MUCH faster to triage issues and PR’s working together with people (e.g. in person or on a call). More people means its more likely someone will have context or insight on an issue, and can help break choice paralysis / feeling of “I don’t know what to do here so I’ll just leave it” when you’re on your own. If people are interested, triaging issues and PR’s with a few people on a call together would be productive I think. I’ve got experience leading this kind of thing, I’m happy to take on the logistics (BUT only if people are interested!).
TDLR: every 3 months retrospective / check in? schedule a few phone calls for pr/issue triage?
4 Likes
I heard a lot of desire for restarting dev meetings expressed at the symposium from @dyfer among others. Not sure what the sweet spot is in terms of frequency- perhaps monthly?
The problem I want to solve is actually not tied to disagreement but providing impulses - we have multiple PRs which are great but abandoned for multiple months/years. IMO most of them are uncontroversial and a minority or nobody seems to disagree on most of them, but nobody feels authorized to progress on them. I don’t think this doesn’t provide a very welcoming atmosphere to contributiors and IMO is a reason on the current lack of developers.
I also abandoned SC development once b/c of this and I’d think it turns off many newcomers as most of development time is not pumped into coding but managing the social aspects (I’d say its something around 70% social interaction, 30% coding for me) - maybe some people enjoy this as a social activity, but I am not one of them as it really drains my personal batteries, but there is currently no other way to contributing (this isn’t sustainable to me personally).
I tried this but what happens if someone voices (a minor) opposition? Who triages now? Also, we don’t have a proper reminder system on GitHub, so such things as deadlines get lost easily there.
I don’t really mind how people organize themselves “within their department”, I really trust the proposed people to make good decision in the sense of the community. I welcome if they ask the community, but this also needs to be organized and structured as a discussion. Currently we tie this to the PR creator, but as mentioned, this isn’t sustainable and the last years have shown that this works subpar, otherwise we wouldn’t have this discussion (e.g. who do I need to ask about changes on scsynth if no one replies to my PR?)
Totally agree on this - maybe we could setup a “smaller”, optional and monthly dev meeting and a “bigger”, more coordinated, dev meeting every 3rd month where we should try to get as much responsible persons as possible into a room in order to coordinate bigger movements?
But this would need to be somehow organized by someone - would be appreciated if someone could take care of such.
Also big +1! GitHub isn’t great for quick interactions, but I personally boycott locked down platforms such as Discord or Slack. I hoped we could use the Chat of the forum to have a more open version of such a space in order to coordinate development and calls etc., but somehow it didn’t take off yet as I hoped.
We could also think about setting up a Matrix space which would be like Slack/Discord but open (cue xkcd: Standards).
I think I could also provide a Jitsi instance from my university for any dev calls if people are interested in this.
BTW, I once did some pair-programming with Christof using shared VSCode instances, which even allowed to share debugging sessions of sclang. I can highly recommend such a setup and there is a PR to make VScode development integration more easy.
2 Likes
I think B is the common issue, but A is also an issue in cases where a decision really does need to be made regardless of controversy. In many such cases disagreements may come down to preferences or a weighting of priorities. It would be good to have some way of breaking such logjams as I think these also lead to a sense of paralysis and bad feeling. I think that having some sort of ‘lead’ or ‘co-developer’ make a (hopefully not irrevocable) choice to proceed may be the least worst option? Other ideas?
I also doubt that this would ever be really just one person making the decision unless it was a lead unilaterally implementing an option only they wanted, which seems unlikely. I think it is very good that we have two or more people in many of the categories above, and we could have a policy that in contentious cases at least two members with expertise in the area would have to reach a consensus?
If there is concern about ‘power tripping’ (seem like rather small fiefdoms to rule, but okay…) we could have a policy of regularly rotating people in and out of these roles. This might be combined with a policy of people shadowing experienced leads so as to build expertise across areas. We often complain there isn’t enough knowledge about aspect x, so let’s build some up! I also don’t really mind who does these, and for myself don’t mind not doing one.