We will not change the world. Sorry.
(disclaimer: this paragraph is just a long rant on the “philosophical” question, if your time is limited, you may want to skip it).
Yes, we will. Actually, I never stated anything about diaspora* getting “big” or making more people care about their online privacy. That’s not what I fight for. However, what I’m talking about, is that we can take care of people who care about online privacy today, and who want to have a good tool while they are fine with some shortcomings like no address book synchronization (which can be viewed as a virtue). If diaspora gets better, they’ll stay, if not, then, these people can turn to “I can’t hide so why care?”. Even if they still care about online privacy, diaspora can make lives of these people better. People do change the world by their everyday decisions. Diaspora community is a part of the world, and by changing Diaspora to better or to worse you change the world. That’s not a goal or a dream or a utopia, that’s reality and we’re responsible for every decision we make in that respect. Dennis, being a maintainer of a projects with large user base, you make a change more considerable, than you would want to. You can state it like “I’m just playing around here, nothing serious”. By this you just ignore all the people who are starving to see “alternative” technologies being developed. And that changes the world as well. You deny that “alternative” technologies is capable of being something more important than just a playground and state that one shouldn’t fight it. And that’s a legit point of view. I disagree with it, I think “alternative” technologies is something that can grow to become a serious tool for a number of people affecting their lives. But that’s not the point. Just don’t say that we don’t change the world. We do, the world changes everyday by decisions of people.
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.
@goob is right, @denschub, you, said that. And afterwards the only thing you did, was only a single message on #908. In any case I can’t force you, so if you just ignore my work I can’t do anything about it. But we need a way to introduce new features and this is a separate issue then, so I created a separate loomio thread for this.
If someone feels like doing management stuff full time, I’d never block that - but so far that has yet to happen.
Actually we can try doing project management collectively using online tools like Loomio.
We could maybe start with a wiki page of things to check when doing a review, which could be useful for both reviewers and developers who want to check their work themselves .
That’s what I miss! Having a nice guide on code review may help both contributors and new reviewers of the project. May we request such guide from the members of the core team? Their point is important here since currently these are they who is define what a good review is in scope of the diaspora* project. If you can’t write a new guide, maybe we can adopt guidelines from some different project/source?
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?
Well, I can’t say anything on improving the code review automation. That’s a rather research topic. However, at least I can say about improving testing by introducing more tests within a test infrastructure, like I proposed many times earlier. Automatic test pods deployment + tests using diaspora client interface. That what can give us more confidence and I need to hear opinions on the progress I’ve made in this respect (e.g. this PR).
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.
It depends on what it consists in. My impression is that making releases is rather a routine operation and can be done without an extremely deep background, isn’t it? I mean that if we find a volunteer who takes it responsible enough, it’s not hard to teach him/her a procedure and take the load from you. It doesn’t require deep knowledge of the diaspora* design.
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.
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.
Basically, with a present situation we end up being completely unable to introduce any big changes to diaspora. Even if there is a contributor who writes something, the “maintenance” part of a pull-request is completely hopeless. So without taking any measures diaspora* will be nearly stagnating.
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.
So basically we don’t need code reviewers to know diaspora source too well, but rather we need them to have good Ruby and RoR understanding and experience. It simplifies the issue in the respect, that we can find someone who is unfamiliar with the code and ask them doing the reviews. However good professionals are rare, and even commercial companies who pay good money have hard times hiring a decent engineer.
So maybe we can keep an aspect in the diaspora HQ account with those podmins, and when a PR feels ready but needs to be tested before being merged in develop, we can ping them and suggest them to test it
I like this idea. Maybe we can even do it in public, so we don’t need an aspect, but, maybe a separate account/hashtag/mailing list/etc.
As we discussed in IRC with @SuperTux88, some PRs are fine with getting tested in a local dev environment and it is possible that we don’t need to disturb podmins with it, but just find some people who are ready to help and do tests locally. To make decent tests one should possess the skill of “breaking things”. So a random person doesn’t fit, but possibly we can still find someone.
I have another idea that just came into my mind. First I thought of making some publicly available test-deployment of diaspora. So that it is easy to perform tests. For example I made PR6818, and I deploy a pod with this version so that people can play with it, try it and try to break it. But then I thought, what if we create a whole separate federation for testing? Starting with a few pods. We may explicitly state it as something unstable and unreliable that doesn’t fit to everyday use. And test PRs freely in it. I’m pretty sure there is a number of people who will happily want to use it and explore. This way we can have pods with upstream vanilla versions deployed there and pods with PRs deployed there and allow developers to deploy their own test pods for any purposes. We can then freely test new things there and don’t be afraid of losing people’s data. Of course, we need some means of separation this from the main diaspora federation, because interaction of the test and the real federation can cause troubles. For example, we can create this test federation within some public VPN network with some local VPN-wide domain names. Thus you can also avoid using a real domain names for testing purposes, which is good, because some kind of damage in data can’t be fixed: if we lost a private key of a user he is lost to the federation.
So to sum up my post.
These are what kind of jobs we have that could help us to avoid stagnation (or if you don’t like it, to speed up diaspora* development):
• a web-engineer with good Ruby and RoR background to do reviews;
• people who are good at breaking things (finding issues) to do decent tests of PRs;
• people who can continuously contribute their time and energy to take the release making procedure away from the core team;
And the other ideas I like are:
• Do the project management collectively using online tools as much as we can;
• Introduce a code review guide;
• Develop test infrastructure (a separate test federation?)
As we all known, volunteers can do a great job. And at the same time, even if we have money to pay someone for some job, it doesn’t guarantee that we manage to find a person who will want to do it properly and responsibly. Also, diaspora* has the image of a project that constantly asks for money and doesn’t deliver what was promised. Unfortunately, I made this situation even worse. (And though it is all my fault, but I still keep wondering why no one from the experienced diaspora* members ever foresaw what it can get to and at least warn me). Having money to pay surely increases our chances to persist and develop, but I don’t feel like it’s okay to ask the community to donate money once more. What about my personal participation, the fact is, that I have to earn money for living. And if nothing changes I’ll have to get a “normal” job after a few months (I already searched for something part-time, but software companies normally don’t like this type of employment). Since I promised that I’ll finish the migration project whatever it stands, I will keep contributing to diaspora in my free time just like the core team does, but that will definitely make it slow to deliver and doesn’t save the project from stagnation (I mean what I said before about the fact we can’t release any big feature).
Sorry, if I missed addressing any other stated points, it just gets complicated enough already.