The core team -- a bottleneck of the diaspora* development

Hi!
I invite you to a Hangout On Air about this.

Thanks for starting this. I am not a technical person, so this answer is not authoritative, but my observations are:

You're right, I think, that the small Github core team has a high workload to get through. However, I see many PRs which are accepted very quickly. These tend to be small, discrete things which are easily reviewed and tested. Your problem, I think - and I understand your frustration - has been that you have taken on some very big tasks which involve a lot of changed code, and perhaps some quite fundamental code changes. This makes it a far bigger job to review the PRs you've made - especially when some of the code could possibly break the app in some fairly serious ways. (Again, I'm only surmising here, as I don't know the reality.)

I remember @denschub committed to prioritising your work after the release of 0.6.0.0, so hopefully things will speed up now. Perhaps he can give you a progress report.

I do think that testing is a bottleneck, and something that people other than the Github core team can do. There are podmins (those who run production pods and those who run test environments) who sometimes merge PRs to try them out live. There have in the past been initiatives to encourage more of these to merge PRs specifically to test them, and perhaps we need to have another such initiative to encourage more people to do so.

I'll be interested to read other responses and suggestions. Thanks for all your work and enthusiasm for the project, @comradesenya.

I like these ideas. I'm honestly trying to figure out how I can do any of these ideas myself if they were implemented. I'm always promoting diaspora*.

Thanks for your feedback, Senya. Yes, the core team has a lot of work and only limited time for diaspora. But you already mentioned some possible solutions.

The number of opened pull requests is always around 25-30.

I think 25-30 is an OK-ish number, currently there are 31 PRs, but 10 of them are WIP, and 6 of them are orphan (nobody works at them, so maybe we should close them?), and I didn't count how many of them are reviewed but have open points. But there are also PRs waiting for review (but not all of them).

Be more risky when introducing the changes to the code and care less if something fails.

I'm strictly against this. I think the high quality requirements are a big plus for diaspora, and I don't want to loose this. More buggy features doesn't help anyone.

Create an "experimental" branch where we merge stuff more quickly with a declared low-responsibility level.

I don't like this idea, because I see to many problems with this:
* Who maintains this branch?
* I also don't recommend to run a pod on this branch. Back when I started running my pod (5 years ago), only the master branch existed, everything was merged there and every update could break the pod (and that happened multiple times, and then you need to rollback, or have a broken pod for a day or two until someone fixed it). And now I can even run the develop branch and I'm pretty sure that nothing breaks.
* We have already enough people needing support with our stable releases. And the word "experimental" and "a declared low-responsibility level" wouldn't stop people here. They also want to try the "experimental" chat, and if it doesn't work, they want help with it.
* If there is a bug in "experimental", which PR caused it?
* Merging stuff without review is also a security risk.

But how can people help?

goob already mentioned it:

There are podmins (those who run production pods and those who run test environments) who sometimes merge PRs to try them out live.

That is a really good way to test PRs, and the people can also give feedback directly to the PR (or ask there for help if something doesn't work with it). When testing PRs directly (in contrast to a mixed "experimental" branch), they know what they are testing and maybe also had a look at the PR description or the sourcecode. I think having that feedback on PRs would help a lot.

But there is also the code-review part, and that is what actually takes time. But you already mentioned the problem with 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.

Code knowledge is important for good code-reviews, but:

Call for more volunteers and give them as much job as they can do without the deep knowledge of the code base.

Everybody can do reviews on github (they even have a nice new review-feature since a few weeks :) ), and with this they get to know the code-base better and better and can do more code-reviews. Maybe this works, but we need people for this.

Everything helps that minimizes the needed "review -> improvement -> review -> improvement"-iterations (That is what makes PRs "slow").

Something else that came to my mind where people maybe can help: If someone asks for help in IRC, it is often one from the core team responding. That is also time that the core-team can use for other things. If people want to help other people, that would be another possibility to relieve the core-team. Fla is already a good help with that.

But I think all of this makes only sense, if the people are interested in long term contributions. That are tasks that you can't do as a one-time contribution. If someone only want to test one PR, we probably need more time to help with the dev environment than we win with the review. But if people start reviewing/testing more and more PRs (and know the code and features of diaspora better) or help more and more people in IRC (and they know the possible problems and solutions), then we can really win time and relieve the core-team.

However, I see many PRs which are accepted very quickly. These tend to be small, discrete things which are easily reviewed and tested.

Often you can split the work in a PR into multiple more or less isolated steps. Splitting the changes into multiple commits helps a lot because then you can also review the changes in multiple steps.

@supertux88 did this in #7113 and I also tried to do that e.g. in #7131 and #7167.

Thanks for taking the time to write that, Senya. Much appreciated. Probably, my reply is more or less the same as SuperTux88', but nevermind.

So, basically, diaspora* has a rare (nearly unique) opportunity to make an important improvement in the technological part of the social development.

First of all, no, we have not. While the idea was to offer a platform for a broad range of people that failed horribly and we will never be able to achieve that goal the way society works at the moment. Communication needs to be zero-hassle and it should "just work", which is why large networks get a lot of attention. Features like automatic address book syncing, which is horrible from a privacy standpoint, are highly requested and loved by users. Due to the way we work, it's simply impossible to achieve that and it will continue being impossible.

I really hoped that, at some point, people start caring about their online privacy. Three years ago, Snowden happened, and absolutely nothing changed. People don't care. People don't want to care. Federated systems that care about privacy will always have their downsides compared to the central counterparts, and as long as people don't care, we won't be the "big one". Never. I have no idea what could make people care when even Snowden did not change anything.

So no, the goal is not to "become the big one". The goal is to build a nice platform where we can play around with stuff like different protocols, find bottlenecks, try solving issues that get big in distributed networks, stuff like that. We will not change the world. Sorry.

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.

The list of PRs waiting for merge <10 items long. All other PRs are marked as "WIP" (which means I will completely ignore them unless I am explicitly mentioned), waiting for review points to be addressed or simply having nobody working on it.

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*.

It's cool that you did stuff full time and I appreciate that, but here's the thing: you did full-time coding, not full-time management. If someone feels like doing management stuff full time, I'd never block that - but so far that has yet to happen. The current core team is based of people that have made a huge impact to the project in the past, but nobody is able to spend much time on diaspora. I wrote a rant-y post here on loomio about diaspora* project management 6 months ago and I asked for people to step up if they wont. So far, nobody made any attempt of getting into management stuff. If this happens, that would be so cool.

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.

Fully blocking this. Take a look at the past of diaspora+, for example its old federation core, and you get a very nice example of what happens if we go the "just merge it" route. Took us 4 years to get rid of that stuff. No, that's not going to happen again, sorry. ;)

• 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.

We already have a development branch with some podmins deploying it to production (like myself, for example). We cannot add a third layer for the reasons @SuperTux88 outlined. Also, goob already suggested what podmins could do, that is, checking out specific PRs and testing that. :)

• Improve tests automation so that less time is spent on the changes testing.
• Automate code review to a possible extent.

We're already doing that. We have styleguide checks and automated tests that run on all tests for every PR. What do you think we could improve here?

Create a QA team who will do the job of making releases and testing and take these responsibilities away from the core team

Sure. Who do you feel like is capable of doing that and are they willing to take that responsibility? Would be nice.

• 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.

As already mentioned, this is possible. Everybody is invited to do reviews for all open PRs if they feel like it. In fact, this has happened in the past: even before @SuperTux88 was a member of the core team, he did some reviews, making it way easier for "us" to review that stuff and merge it, since we know somebody already had a look at it and checked some parts. This really helps and was the reason why Fla suggested him becoming an official "core member". If more people wanted to jump in, cool. #6952 for example is waiting for an intense JS review, #7104 needs testing and ruby reviews. Everyone is invited to tackle these parts.

Also, yes, as Steffen said: small PRs are much easier to review. Large PRs, for example your stuff (still talking to Senya here), is hellish compelx and I don't even know some parts of the sources you touched, making it even harder to review.

I remember @denschub committed to prioritising your work after the release of 0.6.0.0, so hopefully things will speed up now. Perhaps he can give you a progress report.

Honestly? I can't. I recently started a little rails 5 experient since I was in a weird environment and wanted to give it a try since it would make API development easier. The last release was a few days late since I had to deal with other stuff and at the moment, I am fully loaded with paid stuff, basically being responsible for two large projects is completely eating away my brain. If I'm able to do anything after work, that's basically reviewing simple PRs and trying to kick rails5 arse, but reviewing large PRs is impossible. And that'll stay this way this way this year and early next year.

Jonne is also somewhat inactive recently (for very good reasons), which cuts down the number of active people even more. SuperTux is the only one doing really active reviews at this moment, and I fear that your PRs touch code that is beyond his knowledge as well. We'll meet up in person soon, and maybe we manage to do a collaborative review of some stuff, but that's not a promise, just an idea.

Thanks for raising the issues. That's really something we need to think about, but I don't have a solution either. Sorry.

Thanks for all your work and enthusiasm for the project, @comradesenya.

++!

"Three years ago, Snowden happened, and absolutely nothing changed. People don't care. People don't want to care."

Not to put you on the spot man, but this is a bit of an over-generalization. I myself started using a lot more privacy-centric tools since Snowden's publishings and so has my wife (She's actually on diaspora* and uses it often.). A lot of my friends have as well and our local library allowed me to build a privacy-centered kiosk for patrons. But I completely understand what you're talking about. I have felt the same way, many times in fact. But remember, since we all got duped into this crap system, it's a process of getting out of it. But I digress :)

I remember @denschub committed to prioritising your work after the release of 0.6.0.0, so hopefully things will speed up now. Perhaps he can give you a progress report.

Honestly? I can't.

I took your comment at 23:31:45 of our last meeting – 'now that 0.6.0.0 is done, I will focus on senyas pr' – to mean you'd be prioritising his work on account migration. Perhaps I misinterpreted what you said.

I took your comment at 23:31:45 of our last meeting – 'now that 0.6.0.0 is done, I will focus on senyas pr' – to mean you'd be prioritising his work on account migration. Perhaps I misinterpreted what you said.

I understand that as a "If I have time to review a big PR, then I'll pick senya's ones first". But the "if" still applies, unfortunately, and I deeply understand that time and brain capacity can be missing, I feel like that every day :p

tl;dr: the solution is to integrate more skilled people in the core team to review PRs, I feel we're open to that and "just" have to find them, this can be done by improving the way we promote the project

First of all @comradesenya thanks a lot for starting this discussion. That we see the diaspora project as a nice experimentation, a way to try things in a decentralized world, the new Facebook or a needed alternative which has to exist to have a varied ecosystem, I think we all agree that it is an important project and it should improve as fast as possible. We would not be here talking about it otherwise :).

I do the same observation than you about the review process being the bottleneck of diaspora's development. I'm sure the core team is already doing its best and is all made of volunteer so we can't ask them to do more so I'm also looking for solutions.

To me, the best one would be to find more skilled people to integrate the core team, and that's why I suggested to integrate @supertux88 recently. We can already see the benefits of that decision, thank you mate ;)

I feel we're actually pretty open to contributors joining the core team. @fabianrbz for example did some nice PRs and has been invited to join the team pretty quickly. It looks like he is not active anymore though. So, if new contributors come in, open some nice (not too big) PRs which are merged, then start make relevant comments and reviews on other contributors PRs, I feel like there should be no problem to give them commit rights on the code.

At the moment, you're the only one being paid (or have been paid, I don't know how much money is left from the crowdfunding) and of course you can't be both the developer and the reviewer. The solution could be to find money to pay a reviewer. However, the only person skilled enough and who said that he could potentially be interested about that is @florianstaudacher and we didn't hear much about him in the last months. @jhass and @denschub clearly stated that they don't want to do that. I don't know about @supertux88. @steffenvanbergerem is more on the front-end part.

So to summarize, to me the best solution to solve the bottleneck is to increase the number of skilled people able to make reviews and merge code. The core team looks open to include new people if they match the technical (demonstrated with PRs written and reviews without commit right) and philosophical (this is more about the feeling and the same vision for the project) requirements. It is even possible to pay reviewers to do this work, if they are willing to.

We "just" have to find them, and that's why we need more promotion and initiative like "bug mash monday", which bring us to the community management of diaspora, where we also miss contributors now that @deadsuperhero and @jasonrobinson left. There is probably things we can improve here, probably focusing on the new releases we do to show the project is alive and kicking (the promotion of 0.6 was not as good as it could have been for example). diaspora* has to be visible, especially to ruby skilled developers.