Okay folks. The last time I ranted around is not that long ago and sadly, I do feel the need to rant again right now. But this time, I post my rant here on Loomio since that is the platform the diaspora* project decided to make decisions on. And this time, I would love to actually get your feedback on my rant.
I need to write about project management, diaspora* and how I feel about project management at diaspora*.
Status Quo
So, who is managing diaspora* at the moment? That’s actually a very good question. We have that semi official group called “core developers” which is basically defined by the group of people who have push access to the main repository. That list is really short: there is the old core team, which still has push access but they are obviously inactive. Besides the inactive core team, there are four other people with push access: Florian Staudacher, Jonne Hass, Steffen van Bergerem, and me.
Florian (aka raven24) unfortunately, got eaten alive by some real world stuff and is way too busy to be active. Jonne is doing great Ruby work, is great at reviewing pull requests and also great at producing ideas on how to solve issues fast. He seems to be rather busy with other stuff as well, but luckily he is still contributing a lot! Steffen is doing amazing frontend work, which is really appreciated, and he has a great sense of UI/UX. He is also a very active contributor, but like all people involved here, he also has a private life.
So… who am I?
Good question, thanks for asking. I am a software engineer, working on creating software and building solutions for various problems and needs. I work in a small team, where all of them are fellow engineers. We do not really have a manager in that team, which is a decision made by design. We do manage ourselves and we talk to each other to exchange ideas on what we think is important. When we have done our planning, we create tasks in our management system for everything and start doing our work. Other developers in the company will also pick some tasks and join the efforts. This works incredibly well, since that company is very carefully picking their candidates, and the ability to manage themselves is a hard requirement.
As for diaspora+, I quite frankly have absolutely no idea what I am doing. Some people might know me as an administrator of Geraspora, which happens to be the largest pod. Some might know me as a guy who works at that company. Some might know me as a diaspora* core contributor. And some might know me as an incredible asshole. All of these opinions are actually right and depending on who you are and how you interact with me, you might get a different type of reaction.
I used to be a contributor to diaspora*s frontend and backend back when the old core team was still active. As diaspora* was converted to a community driven project, I started doing some more advanced project maintenance work. Nobody ever asked me to do that, but nobody else stood up to do that work and back then, I felt pretty confident about doing it. Right now, most people probably think of me as the person doing all the project’s meta stuff. That is, planning the general development, building releases, trying to prevent the project from evolving into something that’s not desirable by the community, … you get the idea.
Basically, one could say that I am diaspora*s project maintainer. I never got elected into that role, I don’t officially consider myself to be that person, but based on the work I do and the way people look at me, that seems to be a rather suitable “job description”.
And honestly, I do write a lot of code at work and doing project management is interesting and a fun challenge. I never got any professional training on how to manage projects (or people for that matter) but in the past, that seemed to work out well.
What’s in my head?
I want to give you an insight on the stuff that’s in my head. Err, I mean, what’s inside the diaspora* part of my head.
- Release 0.6.0.0 has been in the pipe for a loooooong time and we really need to ship it. What should be included in the release? Should we stop after the federation rewrite? Should we do some more extensive database optimizations to maybe improve the performance? Should we try to make the chat 100% stable, pretty and fancy? Should we push the API development? How much work will get pushed into the tasks and how far could these features delay the release?
- How are we able to rewrite the entire federation without breaking stuff? How can we test the stuff when it’s done to ensure that we in fact did not break stuff?
- Wahhhh, there are 400 open issues and 30 pull requests!
- When we’re done with the federation, how can we publish documentations on that? Should the documentation contain only an implementation description or should we try to publish an actual protocol specification to make it reusable? Will anybody even care?
- How can we get the fundraising supported user migration feature implemented without breaking stuff? How can we ensure the user data stays safe? How can I ensure the contributor will actually come up with a solution that everyone is happy with?
- How can we make sure that the company who is wiling to implement post editing understands the complexity and issues behind that and how can we make sure that the solution actually works?
- Woah, look at all those issues!
- How can we make our project attractive for new contributors? The bug mash Monday was quite a success, should we start that again? Should we try to work with more organizations like RailsGirls, should we try to get our project involved in campaigns like Outreachy, …?
This list is highly incomplete. But you get the idea. There is quite a lot of stuff going on in my head and since I sadly have not discovered a way to stop the time, I only can spend some hours a week to work on that. Besides the planning stuff above, I also do pull request review and similar stuff, which is also consuming an insane amount of time (trust me, reviewing a PR usually takes almost as much time as writing the patch in the first place - if you’re doing your reviews carefully.)
How do I feel?
Most of the time, contributors rant about how bad they feel in GitHub, usually paired with some personal attacks against other individuals. I’ll try to be a bit more neutral here.
(Note: when I am talking about “the core” in the following paragraphs, I am talking about the currently active core team. The projects goals have rapidly changed after diaspora*s transition into a community driven environment.)
I felt pretty good with my role at diaspora* in the beginning. It was nice, a lot of people seemed to enjoy my work and I did enjoy the work of our awesome contributors. Nowadays, I feel like we (as in the core team) have to make a lot more tough decisions. diaspora* used to be a playground for everyone, but now we are actually trying to get a stable piece of social networking software out, which requires us to focus on a lot of refactoring work, instead of being able to implement new features that may be important for our users.
The reasoning behind this is simple: we cannot build new features on a codebase that is buggy and not maintainable, so we need to make the base shiny before we can add more toppings. Everyone who is into software engineering will agree with me here, but users have a different point of view. They simply do not care about how we implement stuff and how happy we are with that, they care about our results and the stuff they can do with our project. Balancing those two requirements is incredibly difficult. Luckily, the core team agrees on diaspora*s role, which is not building a fancy social network with all the features one could imagine, but building a platform to do experiments on. A platform to learn how distributed social networking actually works, where issues arise and how those possible could get solved. This is not the first time someone has written that down, there are a lot of responses on Loomio from various core members stating precisely that.
What does this mean? It’s actually rather simple: if there is cleanup work and feature implementation work to do, do the cleanup work.
And now the tricky part: diaspora* is not only driven by the core team, there are some open source contributors as well. Those contributors do not really care about our plans, they do have their own plans and requirements and they work to get them done. That is absolutely great, but there are two main issues: First, the core team will not get much contributions to the refactoring work, since usually, that’s boring stuff and implementing features is much, much, much more exciting. Second, contributors implementing new features will not get the full attention by the core team since they are busy doing what they think is more important. That’s a very problematic situation and building an environment where building new stuff and cleaning up old stuff can be done in parallel is very hard.
Communication?
I do my very best to put everyone in a situation where they can work comfortable. Both sides, however, have to deal with some trade-offs. If two teams (the “features” team and the “maintenance” team) are working together, there will be some kind of overhead caused by communication, rebasing code, … you get the idea. Most of the time, this works just well, but sometimes, we fail hard.
Yesterday, I’ve found myself in that very exact position. A contributor refactored some code because they thought this is important and they were apparently working on some related code. At the same time, we have our large federation rewrite going on, and the very same components were already entirely refactored there. I thought the mentioned contributor was aware of the fact that we are working on that, which they were not. We ended up with a pull request that is now completely obsolete and we (as in “the core”) have to reject it to avoid conflicts with the new federation base.
At the same day, I have closed another pull request by the same contributor. This pull request was already some days old and other core members have been merging and reviewing stuff in the meantime, so I assumed they were not interested in merging this. I took a look at the changes and in my opinion, those changes were not justifiable since they basically replaced a code block in which two assignments were repeated by a function that removes the need to repeat the lines. However, the commit statistics showed that there was absolutely no loss of LOC and adding another function that gets used exactly twice in the same file with only minor adjustments is absolutely not a reason for me to refactor that part. There was no further description provided so I assumed there was no further reason to add that function, and as a DRY optimization, this was simply invalid. PR closed.
Said contributor was not … not very happy about my decisions and the way I communicated them. I had also included a general note about what I think would be more important, especially since said contributor has provided some public timeline about the stuff they are going to implement and I really would love to see that functionality in diaspora*.
The other PR, which is also unmergable since refactorings to that module were already made in the federation rewrite, things got even weirder. I closed that with a simple “this is already done” and an added “please communicate before working on such stuff”. As said before, I know that the contributor is aware of the fact we are working on the federation base since they already have contributed to some discussions to that exact project, so I assumed they would check if somebody has already done that or is planning on working on that. They have not checked that and they claimed that we should have informed the contributors about the fact that we are already doing this. Quoting that contributor:
Of course, I can write you every day begging “please tell me, aren’t you by chance working on anything that crosses my work, you great team-member majesty, don’t consider me too bothering”. But that’s not how healthy projects work.
Currently, I do have a lot of contact with almost everyone and I know what everyone is working on. For sure, I do not have all the details, but I know that Benjamin (aka SuperTux88) is working on some photo- and notification-related federation improvements at the moment and I could totally have prevented that contributor from starting in the first place. I expected everyone to use our IRC channel as a communication tool and ask if somebody is already working on a project before starting a large project. Apparently, my assumption was false and we have an issue here.
I can haz valid feedback pls?
So, personal insults and totally pointless exaggerations as quoted above are not helping anyone. I will get pissed of, they will get pissed of, no work will be done anymore. What’s the point of this, really? Fighting each other is totally fine if you want to destroy the project, but that’s certainly not my intention.
If you feel like calling me names, fine, go ahead. I don’t mind. You’ll probably make yourself look like an idiot, but that’s not really my department. I can handle that. In fact, I’d prefer if you’d attack me than anyone else on the team since I am not sure they would take it so lightly.
But hell, if you think I am doing something wrong, tell me what I am doing wrong. My crystal ball is broken these days, so I really need your feedback. I am not a professional project manager, I am an engineer trying to lead a project in my freetime. I have no idea about best practises and I have no clue on how we can solve these issues if you are not able to tell me what the issue is. Don’t expect me to read your mind and get pissed of if I fail to do so. That’s bonkers.
There are a lot of possible ways to deal with such issues. For example, we could use a tool like Trello and ask everyone to their personal plans, the current project and done projects to a board. That way, everyone could see what people are working on. We could reintroduce some kind of short, weekly meetings where everyone talks about what they are working on and what they would like to work on.
There are many possibilites. But you know what, so far, I thought we can handle our project without the need of dedicated management tools. Right now, I feel like we should really talk about how to manage this project. This is the only option we have to avoid further conflicts and people leaving out of frustration - including me.
So, if you have read this far, I want your feedback (yes, really, YOUR feedback!):
- Do you feel comfortable with me doing the project maintenance? If no, who would be a better match for this role?
- Are there any parts of my work that you think are great and I should spend more time on that?
- Are there any parts of my work that you think are unhelpful?
- What would be the most comfortable and easiest option for you to learn what others are doing to avoid conflicts?
- Anything else is welcome, too…
Thank you!
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I eventually finished reading your post.
