
Organizational Debt - ingve
https://boats.gitlab.io/blog/post/rust-2019/
======
SkyMarshal
@ 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.

~~~
justinpombrio
> the “boats” project, whatever that may be

"boats" is a person. Short for "withoutboats". From their about page:

> This is the blog of withoutboats, a Rust contributor and a stack of labrador
> puppies in an overcoat.

~~~
SkyMarshal
I know, I checked it out when I read the article. Point is, I couldn't tell
from the HN headline what this was about.

------
wgerard
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%.

~~~
wtracy
The only thing that I could imagine approaching a "complete" solution would be
to have a dedicated secretary who manually writes comprehensive summaries
every few days.

Since that's not going to happen, I don't see any better solutions than yours.

~~~
munificent
I've often wondered how much more productive GitHub discussion threads would
be if you could set them to be rate-limited: Each user can only comment X
times per day and each comment may only have up to Y characters of text.

Right now, it's too easy for people to blast out unedited words and consume
the attention of readers. If they had an attention budget, maybe they would
spend it more wisely.

~~~
marcus_holmes
You'd have to stop people editing their comments, too. Or people end up
responding to subsequent comments by editing previous comments and doing the
whole:

"On subject foo:.... (insert four paragraphs of blather here)

On subject bar: .... (more blather)

In response to your point .... (yada yada)"

thing, and it gets even more unreadable.

I find any serious, meaningful creative discussion almost impossible without
proper threads. I have this same problem in Slack, where interesting,
significant, discussions sit in a thread spawned from some innocuous comment
and there's no way of highlighting it to say "this is significant.

I hate to say it, but old-school, early-internet forums did solve this problem
really well.

------
hermanradtke
> 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.

------
afarrell
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?

------
jillesvangurp
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.

~~~
burntsushi
> 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.

No, that's not a way out, because that's effectively what we started with at
the dawn of Rust 1.0. withoutboats addresses the problems we've had in the
post.

~~~
jillesvangurp
I wouldn't dismiss it that lightly. We tried it and it didn't work is not much
of an argument here because this is exactly how many other OSS and standards
bodies work. E.g. IETF has a process that balances the interests of the
stakeholders involved but there's a clear editorial process with somebody
nominated to be charge. Same with how Apache functions. Or the Eclipse
foundation. These organizations have done stuff like this for a while and they
get to deal with plenty of angry users, politics, and other issues that just
are part of the deal when you have many stakeholders. Even Linus Torvalds, the
prototypical benevolent leader, seems to have come up with a decision process
that kind of works. Not that I would advocate that particular way of working.

The bottom line is that most bigger projects seem to end up with some kind of
meritocracy. Not a bad thing to have a few responsible leaders staying on top
of things.

~~~
burntsushi
I don't really want to get into it, but my point is not that, "it doesn't
work," but rather, "no, we have actually tried that, so there must be more to
the story." A key difference, for example, between Rust and the other projects
you mention is the collective expectation of the community's involvement in
the decision making process.

------
groestl
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](https://github.com/greasemonkey/greasemonkey/milestone/77)

~~~
Drdrdrq
What is that about?

------
wwwigham
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.

------
fogetti
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.

------
jondubois
>> 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.

------
DerSaidin
> 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/](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.

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

~~~
GolDDranks
Rust has an RFC process. However, RFCs have associated comment threads. Do
PEPs have these or can you do suggestions only by addressing a new PEP?

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

------
codeisawesome
Very well written, honest, and instructive post!

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

------
curuinor
December 16, 2019?

~~~
keithnz
the super organized manage to bend time to get things done

------
unixhero
So... Change to Gitlab?

~~~
Vinnl
I don't think GitLab's issues are that different from GitHub's that it would
solve these issues. Perhaps something like Loomio might, which is made for use
cases like this.

------
revskill
[deleted]

~~~
dasmoth
There is. Try clicking the [-] beside a comment title.

------
z3t4
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.

~~~
MaulingMonkey
> 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.

Buried is still searchable and linkable, IRC generally isn't. Poorly rehashing
old discussions generally doesn't help improve the signal to noise ratio
either IME.

It's not necessarily obvious where all discussion should take place either. I
started writing a VisualRust patch to add stdlib natvis files to MSVC
projects, which instead morphed into a better rustc patch:
[https://github.com/rust-lang/rust/pull/43221](https://github.com/rust-
lang/rust/pull/43221)

Thanks to this buried gem I stumbled across in a search:
[https://github.com/rust-
lang/rust/issues/36503#issuecomment-...](https://github.com/rust-
lang/rust/issues/36503#issuecomment-250405902)

If that was an IRC discussion somewhere instead, it probably wouldn't have
gotten done (or at least not nearly so soon), because I'd be chatting and
listening in the wrong channel/silo.

~~~
z3t4
The human brain already filters out sounds (noise) that are not important. It
filters out vision that is not important. It filters out smell. etc. And it
does so automatically. But we can not yet filter out information, and too much
information debt can cause anxiety. And issues can get old very fast in
software as things change, but there is no-one to delete or update posts that
are no longer relevant. I think you where lucky that the 9 month old post was
still relevant. Some organizations solve the organizational dept by
ferociously closing down issue/threads and only work on the open ones, while
also making sure there are no more open ones that they can handle.

~~~
MaulingMonkey
My experience is that desired features always vastly outpaces the ability for
software to keep up with it, resulting in the very triaging of issues you
mention - closing them quickly. The flip side of this is that most ideas never
get worked on, and a lot of them _do_ stay relevant.

Sometimes the code that feature would operate on has changed significantly,
sometimes the need for it has been mooted or enhanced by other changes,
sometimes the change has been made significantly harder (or easier!) by other
changes.

But often the idea on it's own is relatively unchanged, and closed is just
another form of buried - still searchable, reopenable for the right reason.

