First, this isn’t Mozilla, it will never be, and most comparisons won’t work. Last year, diaspora* had 0 employees, will stay at 0 this year, and will also have 0 next year. Creating any specific roles, processes, and dependencies fail horribly because you can neither rely on people to do specific work nor can you expect people to do a particular job. They might do it, but they might also not do it, and it’s their good right not to do it. All I was stating is that, although we have people who tend to focus on specific areas of work, it makes no sense to create specific roles. We’ve been there, and it didn’t work.
That’s super fine if you have the resources to support those initiatives. Such support usually happens by either assigning workforce to get things done or to provide infrastructure for these initiatives. Both are things that we, as a 100% voluntary project without anyone getting paid to do their work (well, not entirely true, because there is this, but that’s another topic), and without anyone committing time or resources to the project.
The assumption is you didn’t arrive on Discourse from somewhere else, but usually, you end up on either the project site, the wiki, or from within diaspora, and that’s where all the relevant information is stored. Discourse is for discussions and discussions only (well, and support.)
Please provide concrete examples that are relevant to this project. I am only aware of scenarios that work within environments with fixed available resources but fail for projects like diaspora* for the reasons mentioned above. What we did and still do are things like making sure we have a list of “help wanted” bugs ready, as well as define “good first bugs”, which add some coordination, but I get the feeling that’s not at all what you are talking about.
You disagree to my point saying “management is awesome, as long as there is someone following management’s plans” with “management can be done well”, which doesn’t address my point at all. The point is: no matter how good your plan is, and how awesome the approaches for defining these plans are, these plans are meaningless if nobody commits to implement them.
Jup, right. And if you take that slider and drag it all the way to the left where it says “community-driven”, that’s where diaspora is. We have a “management team”, which we call “the core team”, and all we do is providing infrastructure and moderation. So while we usually keep some kind of veto-privilege, we don’t make up the rules, and that actually is awesome.
diaspora* has some features and some approaches to things that the “core team” actually did never agree with, but we still have those things, because the majority of people (contributors and users alike) were in support of these things, and managed to express their support with good arguments, so the core team had no reason to veto, and it happened, because people thought it would be a good thing to happen. So, if you want to boil it down to one sentence, it would be “Everyone is diasporas project manager”. All the core team does is supporting these community-driven proposals, and moderate them. Generally, we do not steer them, and our opinion is on the same level as everyone else’s.
I acknowledge that this model has some disadvantages, and it might not be suitable for everyone, but it’s the model we agreed on a long time ago, and so far, nobody brought up enough reasons to reconsider that. And in my personal opinion, this anarchic approach is sometimes a bad thing, but for a project like diaspora, it’s quite fitting.
Ah, I misunderstood that. No, that documentation will not be on Discourse, and I don’t think it should be. If you want to elaborate, we probably should split this off into a second thread, but in short: Editing permissions on Discourse is a mess, while with the new documentation base, people can submit Pull Requests to our documentation. Accessibility on Discourse can be tricky, and while that may be fine for discussions, we should not settle with that for our documentation. Having multi-language documentation on Discourse is pretty much impossible. Also, general discovery (for both users and search engines) is terrible.
The linked proposal describes all web-properties in detail, which will include a FAQ-like thingy, installation guides, development guides, user guides, as well as the official project website. There are lots of cross-links there, and the content will be easily discoverable. Besides that, we maintain this Discourse as a communication platform for authoritative proposal discussion and IRC channels for casual chatter and real-time feedback. We link to those channels from inside our documentation, and links back (i.e., from Discourse to something else) happens within context. As the new project site isn’t launched yet (content work and publishing will happen before the end of May, I hope), I am not sure if this works out as we imagine, but that’s something to come back to if we see it didn’t work out.
I am honestly having a hard time figuring out how to support you support the project, and this discussion is turning into us explaining our worldview, which is interesting but not leading somewhere in regards to bringing this project forward. So, what do you want to do, and what do you need to support that work?