If you look at brand book, you’ll see the gopher there.

I think there are a few different things at play:

• Some people consider working on open source some kind of social happening, others work on technical stuff precisely because they are uninterested in it.
• In many places, what you leave out matters much more than what you put in. Some people tend to take it personal if their feature gets rejected.
• The amount of people who are capable and interested in ensuring that contributions live up to the requirements are far and few between, and it’s generally a thankless job.
• It takes a lot of effort to get things right, but no effort to get things wrong.
• More often than not the person who wants to add a feature is nowhere to be found when it comes to maintaining it.
• Many maintainers who make contributors redo their patches over and over are not interested in wielding power, but believe that avoiding to inflict pain on actual users (if a feature is shipped in a broken state) is more important than the hurt feelings of a contributor (who felt that the proposed feature was good enough for his purposes).
• While there are topics–like performance–where changes can easily measured and accepted/rejected based on that, there are equally important topics–like user experience–where it is hard to quantify the impact of a change. “This change makes the lives of every user worse”–even if perfectly accurate–tends to make the person who cares about user experience look bad, not the person proposing the change.

That’s my experience from working more than half a decade on Scala. It might provide some insight why the project is hemorrhaging contributors who cared about quality and user experience (apart from the harassment issues).

How would this work in practice? User 1 is invited to Lobsters and the account becomes available on the other instances but without posting permissions? would the postings of that account within the whole tank become visible?