The core team -- a bottleneck of the diaspora* development
First of all, I appreciate the job that the core team does for the diaspora* project. They are appreciably high qualified professionals who dedicate their personal time to the project.
On the one hand, diaspora* project has a non-trivial history, high media coverage in the past and still sometimes in the present. Diaspora* has a comparatively large community. There are people who like diaspora* and need diaspora and want diaspora* to develop and thrive. Diaspora* has good conditions for thriving, again, comparatively to many other free as in freedom software projects. Of course one can't know for sure. World is changing fast. Technologies change even faster. Maybe community's interest for federated social networking will go down as has gone down interest for the desktop GNU/Linux as the smart mobile devices market emerged. We may be on a peak now or may be not, but if we are, then we don't have too much opportunities left to retain as a tool that makes the world a better place. I don't believe that the world is constantly changing to the better. I think that some events may turn it to worse. So what I say is not about trying to jump in the train of progress. It rather about giving people an instrument for a change before it's too late. Of course I don't like to present the thing as a Mission, but that is what I believe diasporians want -- a tool that will make their lives and the world better. And if diaspora* fail, then they may at the end decide, "fine, I like the federation idea, but I can't replace facebook with it, so whatever". So, basically, diaspora* has a rare (nearly unique) opportunity to make an important improvement in the technological part of the social development.
On the other hand, diaspora*'s growth rate is limited mainly by amount of the core team participation. In the past I thought that decent free software projects stagnate nevertheless because there are not enough coders who want to participate. At least for diaspora* it doesn't seem to be true any more for me. People who maintain the project -- the coreteam -- these are who are responsible for planning, QA, code review, releases, they are the bottleneck (they can do coding also, but that's just a special case of a random contribution :)). The number of opened pull requests is always around 25-30. So there are enough people who write code. But it gets painfully long to get the code reviewed and merged.
I did some job for diaspora*, and it still hasn't received sufficient feedback. I did my job full-time, and this means that having one full-time coder at the time is too much for diaspora*. I know I'm not that brilliant as a programmer and I could have done my job better, so that it took less time of the maintainers to explain their points to me and to spend less time testing my changes. However I am capable of 1) improving and learning; 2) getting things done. I gave a resource to diaspora* that many other free software projects don't have. And it was spent inefficiently. That formally is my fault, but I'm also very surprised with the fact the core team members never helped me to avoid this issue, like it isn't in the interests of the project.
Of course there is nothing wrong in that people from the core team want to share only some limited time as volunteers. They have jobs, families and all the different things people normally have. And they participate to the project for fun mostly, not for some high idealistic goals like that which diaspora* began with. So we can't demand more participation from them.
It's a complex issue and I don't now how to solve it. The issue is that you can't catch a programmer a make him/her do a code review that she is unfamiliar with. You need to know the code base to do the job that is the bottleneck currently. Or you doesn't? I don't know.
So what I think of we can do to solve this issue as a brainstorming:
• Be more risky when introducing the changes to the code and care less if something fails. Value development speed (to a reasonable extent) more than stability.
• Create an "experimental" branch where we merge stuff more quickly with a declared low-responsibility level.
• Find some risky podmins who are ready to test highly experimental features.
• Create a target group of podmins who will install highly experimental versions and give a verbose feedback.
• Improve tests automation so that less time is spent on the changes testing.
• Automate code review to a possible extent.
• Create a QA team who will do the job of making releases and testing and take these responsibilities away from the core team
• Call for more volunteers and give them as much job as they can do without the deep knowledge of the code base.
• Take someone and train him/her to make code reviews of the proposed changes.
• Collect some money and spend them on something of the above or something else.