Two years ago Max and Daniel left the project as core contributors. Since that time the diaspora development goes on (thanks) but without a specific goal. A project without a goal is a project without success. For example 10 month ago: https://www.loomio.org/d/VMg5HlpZ/diaspora-the-next-12-months
How to tackle this issue?
We should change the process model. Someone should be responsible for planning the next release and communicating about it. We know the wish list is long enough to pick one feature for the next release. Let’s focus on one feature for the next release and work together on it. I believe we can make more progress towards our goals (to be defined).
First we should discuss about the current development process model. How we select new features and how we focusing on them. Imho one or more leaders should be responsible for the release planning and developer communication.
@diaspeu it could be an approach, but it’s really different than the way we currently deal with the development. I’m especially surprise by the “Only accept pull requests related to the 0.5.0.0 release”. Why would we want to block any contributions?
I think I get your vision here, your point is “let’s focus on something specific we all agree and progress step by step”. It’s not a bad idea, the problem is we are all volunteer, so we just have no idea when we will have time to contribute, develop or release. So all planning is useless, it will not be respected.
Why would we want to block any contributions? Currently 27 developers working more or less on 40 different pull requests. Let’s split a new feature into 27 subtasks and focusing on them.
Basically whoever has access to the main repo is the default project manager. Diaspora has sort of stalled ever since the original dev team broke up and it became a totally FOSS community project. We still don’t have chat. Youtube support is still half-broken. There are no group pages yet, no event pages. Lets just focus on the stuff that has been needing to be fixed for years.
While there are good ideas in to this approach - I cannot see this kind of planning work with our current developer/contributor base. We have a large project with a large code base and project high project maintenance costs - but only a small amount of developers, and even less other project maintenance people.
Personally I see the current way quite good. Important stuff is labeled as next release and everything else is merged in as it gets ready. The large items are slowly done as fast as people who are interested in working on them get them done.
All the devs who work on this project do it for fun - I don’t see how restricting what they can work on will make them write more code
All in all - good ideas and all, but we need more organization to have more stricter development cycles. Of course that is not to say we shouldn’t improve and evaluate - that happens all the time, like the decision to go for a 1-2 week merge freeze before a release, just as one example.
All the devs who work on this project do it for fun - I don’t see how restricting what they can work on will make them write more code
Which is a very valid point - I think we (as end users) are extremely lucky to have people working on this at all. I’d be against something which says “You there, developers, you must do this before that or else”
(which is how it may come across, intended or otherwise)
Don’t get me wrong. The reason is focus. For example https://github.com/diaspora/diaspora/pull/4410 some nice guys worked together and the new single post view come to live. Sometimes, the issues are too big to be resolved by one man show. Split big features into small subtasks and focus on them.
@diaspeu the work “all together” on the new SPV was awesome, and we all want to see that happen again. In my opinion, the best way to do that is to coordinate ourselves like “let’s all block next thursday to work on diaspora*, meet on #diaspora-dev and hack all the evening together”. If we success to plan something like that, then it makes sense to prepare the work to do by choosing a task, splitting it in subtask and affect them to a volunteer, etc. But to prepare the work without having a work time planned is useless imo.
@flaburgan I like the hack together idea at same time. But because of timezone the work packages should be selected, described and prepared for the next release.
@diaspeu Working together on the new SPV was a nice example how working on diaspora* could look like. There was no real plan to do it. We all talked about changing the SPV but there was one dev who started working on that and did a lot of nice work. Then others came across and helped. The same thing could happen for chat or groups. We “just” need someone to start working on that issue and spend some time to get the basic stuff done.
@diaspeu That’s because of a lack of people qualified to review that code rather than a lack of a goal. Everyone on the project thinks of an API as a priority goal, so it’s not been left because no one cares. We need more developers!
I think every discussion about the project will finally arrive to that point. So let’s focus on communication and make the project innovative and sexy again.
In the future, I think a good idea would be to write an official blogpost to definitely kill all false idea about the project (founders went in vacation with the money, etc…) (yeah, I heard this one more than once). Something like “the real history of the diaspora* project”, explaining everything the founders never talked about when they probably should. Once this will be done, we can start again on solid foundation.
@flaburgan Incidentally, I am working on a personal post that talks about everything that the project went through, from being a startup to pivoting to a community-run organization, and everything that happened between those periods.
I plan on posting it as soon as it gets finished; it’s kind of a long story, but I’d like to think that it’s a really good one.
