Organizational Debt

@ OP & HN mods - just fyi, it’s not clear from the title or URL that this is about the Rust project. Might be worth adding “(Rust)” or something to clarify.

Anecdotally, I for one am not interested in the topic of organizational debt in general or wrt to the “boats” project, whatever that may be, as I’ve read and experienced quite a lot about it already. But I am very interested in it wrt to the Rust project, given their clarity of thinking in other domains. I clicked through and read this anyway, only b/c it’s Sunday and I’m not in a hurry to scan the titles and urls only and quickly decide what’s interesting to me. But on other days I might have skipped this one just due to the lack of important information in the post line.

Re: Github Discussions

Preface: I don't think this resolves the issue completely by any means.

It's seemed clear to me for awhile that Github discussions need threading, badly. The 200 comments on one of those issues probably amounts to about 40 actual discussion topics. Many of them are the original poster adding follow-up comments to their original comment, or back-and-forth discussions about one single comment. It's especially noticeable on contentious discussion topics.

Basic conversation threads wouldn't completely alleviate the problem--200 threads is much better than 1000 comments, but probably still an intractable amount for the maintainers. Still, it might mean you're able to scan 75% of the discussion instead of 25%.

> there is so often not a reciprocity of empathy from the other side of the discussion

Being part of an open source community must be a two-way street. I have contributed a little bit back and weigh in sparingly. I am shocked how demanding and entitled some people can be, especially those who have given nothing back.

> the community has no defined boundary of membership

I realize having the time to contribute to open source is a privilege and we should be wary of silencing voices who may have good ideas but not the time to contribute. However, I also believe that the amount of noise is drowning out the signal. I am in complete agreement that we desperately need to define what membership means.

Is there an open source project which has done a good job of bringing on Product Managers and establishing norms of how they interact with the community and how they manage the process by which broad consensus is built?

Rust is definitely drawing in a large crowd of highly opinionated and smart people that each have lots to say. That can indeed generate a lot of noise.

There are a few risks when that happens. One is that the debates can get kind of toxic and political. This means you get people skilled at politics dominating the discussions. This both drives away people and attracts more wannabe politicians. Worst case you end up with a lot of politicians in charge. The other risk is that you inevitably get schisms, factions, and people going off carving out their own niches all while sucking up a lot of energy with debate, arguments, and the inevitable fallout of that. IMHO this is exactly what happened with e.g. Scala.

Rust is not quite there yet but I'd say it is starting to attract a lot of the same type of crowds meaning that, as this article identifies, now is a good time to do something about it.

One way out is simply imposing some hierarchy based on meritocracy. It starts by acknowledging that somebody needs to take decisions and that not all opinions matter equally. Find some respected long term committers and organize decision making strictly around those doing the most work. It works well in other places in the OSS community. You build it, you own it. You want to contribute, you need to learn to work with those that are going to be in charge of accepting your work.

If you have too much organizational dept, you can also go bankrupt, right? Yes, seems that some projects actually did that: https://github.com/greasemonkey/greasemonkey/milestone/77

I really empathize with the community interaction aspects of these comments - having spent a few months triaging everything that comes into our (admittedly less organized) repo, I can very much understand. It can be truly draining to only see the negatives and the nits and the nags and the bugs and the bothers and the badgers of a product. Heck, it makes it easy to forget about all the people who love it, those who've never once complained and silently continue about their business, able to ignore the fact that work had ever been done (and continues to be done).

But... It's swell when you meet someone and they offhandedly mention using the thing you work on, heck, even recommend it or straight up take it for granted. I know those moments probably can't sustain open source maintainers (and that leads into the second point about capturing funding), but, at least in my experience, they really help keep a more healthily balanced perspective. And that's at least a part of being able to stay happy working on such a project.

With respect to funding... As a relatively young compiler dev, I've pretty much always taken compiler software for granted. It's (almost) always been that languages have been freely available, and usually the source available, too. If I'm honest, at the price point of "free", it's almost hard to picture how compiler engineers get paid at all. Normally people sell tools, but... Programming languages are now tools freely given. And now even their advanced refactoring tools and IDE support. Strange to think about it, if I'm honest.

Github comment threads are basically like a kicked over dumpster which has all the content landed on the floor. I hate going over them. Something like a stackoverflow style organization would improve a lot.

>> Using GitHub issues to discuss design is like drinking from a firehose

It depends what kind of community you have. I noticed that projects which have received a lot of hype tend to lose their thought leaders and they often end up with highly divided communities and opinions. Also, when people jump on the hype bandwagon too quickly, they set themselves up for disappointment and discussions become more emotionally charged. This is made worse by the fact that the most emotionally invested people are more likely to get involved in discussions.

> It becomes overwhelming and exhausting

> It becomes harder for users with genuinely new insights to participate because they can’t tell if their insight is new or not and may decide just not to post it.

> Working groups need a toolkit

I wonder if that toolkit might look something like: https://www.kialo.com/

Structuring and organizing discussions like this might make them more scalable.

One difference is Kialo only seems to support binary arguments. There may be more than two design options.

Instead of discussing ideas in threaded conversations, you could try using standardized proposal documents. It works well for Python.

How bad is it if everything on that list applies to my day-to-day responsibilities at work?

Very well written, honest, and instructive post!

Clearly there's need to introduce a process for Rust Improvement Proposals.

December 16, 2019?

So... Change to Gitlab?

[deleted]

Just use IRC ... the problem with writing down all ideas and all discussion like with Git issues or a forum is that the few good ones get buried in all the shit. With IRC you can only have one or two discussions at the time, so you won't have the problem of following 30+ simultaneous discussions. IRC is a form of grinding, after some time, the community will have reached a consensus, and all arguments for and against something will be known by most regulars, so when someone new joins and say something that already has been discussed a thousand times, one of the regulars can say that these are the trade-offs and this is why it has not been implemented. Good ideas or important issues will be repeated over and over until they are either implemented or fixed, so prioritizing issues becomes natural.