Organize ourselves

I think it is time now to organize, put roles and delegate tasks. If we organize ourselves, new contributors will be effective more quickly.

What I want to do is to define what Diaspora project need, make groups and put a “leader”, a referent, who will be the person to address when you are newcomer.

So, here we go. We need :

To improve Diaspora.
Here, we need at least two technical referents. We can divide this big group in subgroup like Bugfix, packaging, federation, UI, mobile, etc.

Maybe we can add a different group : To deploy Diaspora, which will contain packager and podmin, who can support new podmins and every people who want to try set up a pod.

To document how Diaspora works.
King of the wiki, your place is here. To have a global vision of the project is really needed, including how we are organized…

To make tools around Diaspora.
The platform, the website, the wiki, a forum, maybe a mailing list, but also tools like

To communicate.
With the media, with the people… This groupd is in charge to talk about what diaspora is, what is done by the community, to find new contributors, to help them insert in the right group, to listen to the users and their ideas, suggestions, etc.

To translate.
This is pretty simple to understand. We need at least one referent by language supported.

To support.
This group has to help user, on irc #diaspora, on the forum, on the mailing list, on Diaspora directly…

So guys, what do you think about these groups ? Can you find a referent / “Leader” for each one ?

Note: This discussion was imported from Loomio. Click here to view the original discussion.

I believe we can do it.

Sounds good to me! I still think that we could learn something from the Mozilla Project. Somebody should do outreach to them, and ask for advice on starting a new community. (As Mozilla/Firefox did, when Netscape released the code.)

I’ll do it myself, if I have time.

I am a contributor of the Mozilla Project and these groups are those currently used by the French community :wink:

But feel free to inform yourself and summarize it here about the organization of the Mozilla Project :wink:

@brentbartlett I think that’s a good idea, we should definitely talk to some people from Mozilla about things they’ve done as far as community-building is concerned. Can you think of anyone off the top of your head that might be good to try talking to?

@seantilley-communitymanager Unfortunately, I don’t really know anybody working on Mozilla. I was just going to dig around, and see what I could find.

@brentbartlett Let me know what you come up with, I’d be happy to help in your search. :slight_smile:

It’s a shame to see 7 months later that we are not more organized…

This nice powerpoint has a lot about building the mozilla community:
Though maybe that’s about building the community once the software is at a slightly more advanced level, given that they already had a functioning browser…

I don’t entirely understand the discussion context, what do we mean by ‘referent’ “leaders”?
I think the idea of groups is a good idea though…

I agree, Fla, that it’s disappointing we’re nowhere further forward after 7 months. I’m wondering what concrete proposals we can come up with.

Obviously one form of organisation is to do with setting up a foundation, which would then enable donations towards development and so on. Things are apparently progressing behind the scenes on that matter, so we’ll have to see what happens there.

I think it’s a really good idea to identify certain key areas and to set up working groups according to the system you lay out above. Some of these areas would be:

  • federation: separating it into its own layer (and, when this is complete, improving federation performance)
  • account migration: this is crucial and is being discussed here
  • encryption: I have just started a discussion about this here
  • packaging: there is a Debian group, and it would be great to encourage the formation of groups to work on packaging for other distros/OS
  • documentation: make documentation of code-base and user guides complete and easy to understand
  • communication: as you say in your intro.

There will also be other groups which form spontaneously to solve particular problems, such as that which has formed to work on a chat feature.

If we can agree on the necessity of setting up dedicated groups to work on these key areas, and find a group leader/co-ordinator for each of them, I’d like to start publicising this and making calls for people to join one of the groups to bring their expertise to the issue.

What do you all think?

(Nick, by a ‘referent’, I think Fla means someone to whom other group members will refer things; a group leader who knows the issue and Diaspora well and can co-ordinate people’s efforts.)

On the contrary, I don’t think it’s entirely fair to say that we haven’t moved at all. If anything, the community has done a wonderful job of coordinating releases, getting newcomer devs into the loop of how things are done, and updating our existing documentation. We actively engage our users in social media channels, and provide help to prospective podmins that get stuck setting things up. In turn, our install docs have really improved as well.

At the very least, I think our project is much better off now than it was a year ago. There was a brief time that Diaspora wasn’t getting any attention at all from the original core team, and the future of the project didn’t look great at the time from anyone’s perspective.

The real sticking point, from my perspective, is developer muscle. Federation, encryption, account migration, these things are complicated things to wrestle with. Half the battle is knowing how these things work and come together.

With that all being said, I would definitely be supportive of the idea of breaking down development into specific teams that want to work on these particular things. I know @dennisschubert and @tomscott have both expressed interest in working on XMPP chat, for example, and @l3mncakes wants to take a look at federation.

I think we should focus on encouraging these kinds of explorations and collaborations. I also think this might break down the workload for all of our current developers.

Our project is growing still, and it may be a good time to start thinking about future infrastructure that might suit the project better.