You already are. The strategy is to use Discourse to have discussions on proposals and ideas, and to have voluntary developers working on whatever they feel is important to them, because this is a voluntary open source project, not a commercially developed thing where someone can tell someone else what to work on. If you want to be part of how the project develops, read and engage discussions here on Discourse. Also, check out this discussion. And keep in mind that diaspora* is not Firefox, and we don’t have a marketing or QA department, we are a bunch of folks working on the project, and while some people tend to focus on some things (like @supertux88 is mostly tackling federation tasks, while @goob is great with engaging with the community and doing support with the HQ account), there are no dedicated roles, and there are no dependencies on each other’s functions. There aren’t enough people in the project.
That’s cool. Our Get Involved page on the project site outlines some possible things to work on, but in general, the best way to do something is to do it. Unless it involves you looking like you’re representing the project in any way, you are fine to do whatever you want. If you have an idea and want to get feedback on it before doing something, you’re already on the right platform to do so.
First, “agile” is just a meaningless label that gets slapped on many different ways of working, so you have to elaborate. Secondly, I am afraid I have to disagree. Any form of active PM’ing requires someone to follow along with the tasks and do those. We tried defining milestones and goals many, many, many times before, but in reality, this is a useless exercise here, because no PM in the world can make things happen. Our contributors, both in engineering and non-engineering roles, contribute because they want to work on something, and they work on whatever is right in their opinion. You can assign labels and priorities to issues all day long, they won’t resolve themselves. So, in this project, the way to go is to discuss about those things (which is happening here very often) and convince the Engineering folks that this is something they want to do (and by that, I mean with rational, valid arguments, not by repeating “I want dis” over and over again). If you get someone excited about something, chances are high they are willing to spend time on it.
I’d love to explain things, but… you didn’t ask any questions? If there are questions about why something is the way it is, please ask, I am very happy to help.
First, get some solid documentation going with a clear path to support. Why not use Discourse?
That’s exactly what we do. Our project site as a “Discussions and Support” link in the header, which links to this Discourse. Here, we have three categories: Support for user support, Podmin Support for podmin help, and Developer Support for questions about setting up development environments or general, non-issue-specific discussions around the development workflow. There is Website, Documentation, and Discourse for discussions on our documentation contents (which soon will get relaunched with a more stable, flexible, and maintainable base as well as new contents), and we have Communication and Outreach for coordinating what you’d call “marketing pushes”.
I am struggling a bit to answer to your post, mainly because it didn’t involve questions, and is suggesting things we technically already do. Is the information behind the links above useful to you? Do you have any concrete things you’d like to tackle or concrete questions? If you want to have a 1-on-1 chat, feel free to reach out via … things. IRC works (Freenode, Mozilla), other things might work as well, but I probably prefer discussing in public, because this information can benefit other folks as well.
No, no, not at all. Signed, a Mozilla employee.