Project management at diaspora* - or: what the heck am I doing here?

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


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 stopped reading about half-way through or so because my opinions and thoughts were distracting me :stuck_out_tongue: I eventually finished reading your post.

After about 10+ years of hacking and chillin’ in the FOSS world, what I’ve found common amongst the strongest FOSS is that there is an organization AND community working TOGETHER in order to achieve various goals.

By “Organization” I mean like a Non-Profit (As an example).

Look at GNU, Mozilla, The Document Foundation, etc.

Another common trait is that they are also spun off from other projects/influenced by other projects. LibreOffice = OpenOffice, Firefox = Netscape, Ubuntu = Debian, GNU influenced by UNIX.

Also, for what it is worth, I’ve had fantasies of taking the “Project Manager” position that @deadsuperhero once had back in the day. I find that “Leading the way” is a common role that I play in life with damn near everything so hell, I’m willing to do it. I have a shit ton of ideas on the future of diaspora*.

All for this one,


Also, I edited a certain part out because I didn’t care for what I originally said. Just FYI.

Do you feel comfortable with me doing the project maintenance?

I read all of it and I think you are doing a really great job for diaspora! :heart:

Are there any parts of my work that you think are great

I think you (and the core team) have the correct priorities (quality before “as many features as possible”), many features doesn’t help us, if not even the basic-features work properly.

What would be the most comfortable and easiest option for you to learn what others are doing to avoid conflicts?

I don’t think we need more tools for this. We have github for development-discussions, we have loomio for decisions and discussions, and we have IRC for quick questions.

Maybe meetings are a good idea? There were some meetings a while ago (Meetings - diaspora* project wiki), but I don’t know why they ended?

It’s not easy, but maybe someone else has an idea how we can improve communication?

Anything else is welcome, too…

Thanks again for your work on diaspora, you (and the other from the core) do a really important job for diaspora!

@theatrex: And what would you do different than Dennis? If you only have ideas what diaspora needs, you can simply create issues on github, but we have already enough issues :wink:

And how can you manage a project when you can not even read the whole post of Dennis?

Hm, I do not really have feedback, from my point of view you seem to do well what you do. Okay on that special case maybe you weren’t perfect but… afaik you are pretty similar to a human and humans tend to fail ;D

Erm a little question: what is LOC and “DRY optimisation”?

(by mobile)

@deusfigendi LOC: “Lines of code”, DRY: “Don’t repeat yourself” (don’t write the same code twice)

Just for clarification, Sean was a community manager for diaspora, not a project manager, which is a somewhat huge difference…

Also, I’m sorry, but if you only have a “shit ton” of ideas, that’s probably a pretty good reason why you actually should not manage a project. We don’t have a lack of ideas, but we do have a lack of ressources to implement them.

I withdraw my proposition. Good luck!

I did read the post. And fair enough. Cheers!

The good point is that you have become aware that you obviously have communication problems. The bad is point is that I doubt you are able to change.

The problem is that the way you talk to people drive contributors away. This is my case. And I assume that this was also the case of Jason.

You may be doing fantastic technical work, I won’t judge that. But in the end, it remains that non-ore devs have to work with you to contribute. And this is my opinion on the matter : working with you is not fun. And this is a problem because working for a free projet has to be fun to attract new contributors.

I think that diaspora will not attract new developpers as long as you are still around. And even if you ae doing great technical work, I sincerely doubt that the benefit is worth the cost. So, IMHO, the best you could do is just leave the project alone.

That said, I am perfectly aware that this is not what you are going to do. But you asked for feedback. So I give mine.

1 Like

Augier, I really do appreciate your feedback! You are right, I will not leave the project. However, if there is someone who is passionate about doing the communicating for me, I would be happy to collaborate. :wink:

Well, I won’t do the communication for you but I can give you some hints. Your reaction on this PR from Senya, for instance, is totally inappropriate.

You don’t start by saying

Senya, but this PR is absolutely wasted work.

This is not the way you talk to a contributor. Whether you want it or not, you have to show some respect to people that are eager to contribute.

You just could have said :

Hey, Senya, I’m sorry you wasted your time, but SuperTux has already refactored large portions of it.

The same way no need to say :

Sorry, but you are aware of his work and you should really communicate before touching anything regarding the federation layer.

What I personnally read here is :

Hey, talk more, you fucking idiot!

You should have said,

I don’t remember you saying that you worked on this part. Have I missed something?

You really need to keep your mind open to the possibility that you, too, can be wrong.

The reaction of Senya to your post is perfectly understandable. But your answer is completely childish :

Could you please tell me when you wrote a quick “fyi, people, I’m planning to do some refactoring on the notification work in the next weeks” in IRC or in one of our mailing lists? I try to read the backlogs in #diaspora-dev as much as possible, but if it turns out we’ve missed something, we maybe should think about how we communicate.

Really, who’s fault here is not the point. The correct reaction would have been:

Ok, there must have been a miscommunication here. I can’t remember when you said that you were working on this but that’s not a big deal. Closing this. Don’t hesitate to open a new PR when you have looked at SuperTux’s work.

And you signature

His Majesty King denschub the Fifth

Is litterally saying “Hey ! Yes, I’m making fun of you because I have absolutely no respect for your work. Now go back to your things, you retard because you’re wasting my time”.

I can understand if Senya didn’t say anything to you as half of the sentences you write can be interpreted as a personnal insult. You may be not giving any shit about being insulted, but most people out there do.

These are just some points. But, IMHO, you really should see a communication coach. Because I doubt that you talk this way only on internet and I doubt that it has never been a handicap to you.

Hi @Dennis and thank you for your ‘rant’ and your sincerity, that make things more clear for me on how d* dev works and how you feel. I can not answer all your questions. Just some thoughts (but I’m no expert) :

  • there is a need that someone or a few people review the PRs and decide or not to merge it (i.e. : be the guardian of diarpora in some way. So if you do that, I appreciate and I thank you.

  • therefore contributors to the code (at the origin of PRs) needs to be informed about the policies of d* (priority to solid and clear fundations…) and that their PR might not be merged or need more work if not corresponding to the goals / rules. The goals/rules should so be clearly written somewhere.

  • contributors may be able to find easily info about who is working on what (and the progress of this work) and what need to be done and is not assigned. Obviously, as a recent discussion with contributors shows (e.g. here ) there is a need for a kind of *online team board ** with all that infos (d, irc and github does not seems to be sufficient).

  • arising conflicts between people (whatever are their origin) are detrimental to the diaspora project (or any project) and should be quickly resolved so that everybody is happy and diaspora can be made better. To resolve conflicts everybody should restrain from using irony or sarcasms which are, to say the least, unproductive, but rather stick to the Non violent Communication described by Marshall Rosenberg or any other communication method. NVC is easy to understand, hard to use but is really worth it, be it on online or in real life (info here : ).
    (I remember the Pistos fork of diaspora because of communication problems of the core team years back, and I see it as a waste of time/work/human)

  • I agree with @Augier about finding a way to say things without hurting people and making them sad or angry (the point of NVC, by the way). I believe that efficiency and/or being true to one’s values (diaspora must be clean code and solid and simple…) would be as or even better served by direct and strong positions in comments/discussions that bears empathy and goodness instead of ironic or curt/abrupt sentences. This is the difference between authority and authoritarism. One can still be efficient and strong with empathy and goodness. I believe this is even more efficient and makes people happier which in turn brings better work and attracts co-workers.

  • I really hope something good for you, other d* devs and the users will come up from this discussion. Where I disagree with @Augier is that I believe everyone can change himself/herself provided that the will to do so is driving him/her even if this is hard work.

Thanks Augier! The man issue is that people try to imagine stuff into my answers which I did not write since they feel like they know what I am writing. Mayybe I should start my texts with a “Do not read between the lines, you won’t find anything there.” :wink:

Augier, you need to explain something. Could you please describe the difference between your suggestion:

Hey, Senya, I’m sorry you wasted your time, but SuperTux has already refactored large portions of it.

and my answer:

I’m sorry, Senya, but this PR is absolutely wasted work. @SuperTux88 has refactored large portions of that code already

because I seriously am not able to make out any difference here.

But, IMHO, you really should see a communication coach.

Good luck teaching an Aspergers guy how meta communication works!

To resolve conflicts everybody should *restrain from using irony nor sarcasms

The interesting thing is that I almost never do that and in the very rare reasons I actually use sarcasm, it’s about funny stuff and I usually add some funny cat emoticons do that. Unfortunately, most people seem to think that I am sarcastic all the time.

Thanks so far for all your feedback!

Ok. Maybe sarcasm is not the right word here but irony still is I think.

There is not much difference beetween the two sentences you quote indeed and this one was a not a good exemple Augier picked up, but his other exemples are right I think. I truly encourage everybody to have a look at how NVC works. Everybody should be able to find info in his/her mother language on the web since NVC is becoming widespread.

In NVC, difference is made between what one person say and the person him/herself. Here I have nothing to say about anybody but just about how we communicate.
To say that someone is sarcastic is wrong because this judgment is adressed to the person whereas saying that someone as written something that one feels sarcastic is all right because it is adressed to what he/her write and not to what he/she is (or more precisely one judges he/she is). This is subtle I agree, but to me it does make a lot of sens.

Back to the topic. If some people would feel hurt by what I write, without me willing to hurt them, I would then make sure that my words and sentences are written in a way to avoid any possibility to be read between the lines with another meaning that I do not want to be read (that’s why irony is to be avoided I believe). Even if it costs some reflexions, psychology insights, efforts and time to write more. I think it is worth it, and eventually it will become a habit. But I know this is not simple nor easy and I hope that what I write does not make the impression that I have the only answer to all questions here.

First of all, thank you Dennis to open this topic and ask for feedback. This is definitely a step in the good direction. It’s really brave to ask “what do you think about me” being ready to hear what others can say.

I’m also happy to see that we have pretty similar things in mind :slight_smile:

Do you feel comfortable with me doing the project maintenance?

You are definitely doing a great job technically, as far as I can tell. You are also talking raw, and I find that rude sometimes, but I guess this is a matter of culture and I’m used to it now. Jonne is also like that sometime. So yes, I’m totally ok with you doing the project maintenance.

About the communication to avoid code conflicts like in #6834, I posted my suggestion there. I can say it again here: both Senya and SuperTux88 work can be followed, but there is place for improvements: @supertux88 could post small updates on the issue regarding federation when some significant work has been achieved, @comradesenya could open an issue when he plans to work on a big task to ask if it’s a good idea or not. The problem here is, he is working daily, so the core team needs to answer “quickly” (maybe in at least less than a week?) to not block his work. I feel like either you or Jonne are enough around to successfully do that, it’s not a review, just a go / no go, so that should be fine. Not that there is already some issues with suggestions unanswered though.

I also feel like we should not use another tool, github + loomio + IRC is enough, I have months of loomio discussions late already, we will waste precious time if we add a new channel. But I would love to see the IRC meetings back, maybe weekly as you suggested so that will keep them short.

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

Exactly. And that means

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

will not be a problem if community contributors are good developers, because they will agree with the previous quote. In the special case of Senya, he is doing refactor stuff, so I feel like we don’t face this problem here.

But hell, if you think I am doing something wrong, tell me what I am doing wrong.

I only have one specific reproach here, the sentence which started the fire:

please don’t move code around just to get some PRs for your crowdfunding campaign (at least thats how it looks to me at the moment)

(From the dry PR). That specific sentence was really mean. This is definitely not a “read between the lines” here. So here is the only real advice I could tell about the way we are communicating: do not make assumptions, do not judge anyone. It is totally fine to say “We will not integrate this change in the software”. Really, everybody knows that a pull request is a request, and an request can be refused. If someone is not ready to see his work refused, he should not contribute to free softwares that way. So a project maintainer has to say how things has to be done, he can say what should be done (at least defining priorities, but as we are volunteers of course he cannot stop someone to work on something) but he should absolutely not judge why someone is doing that. It’s not his business, it’s not part of his work. Someone said “I offer you this change”, the maintainer can say “thank you”, “change this”, “no thanks”, but not judge why. It’s really this assumption which created the trouble. This was the only critic / advice I have on the way you communicate, and I’m sure you can improve yourself on that :wink:

However, if there is someone who is passionate about doing the communicating for me, I would be happy to collaborate. :wink:

Not sure how to do that, but we can try together if you want to.

@denschub First of all, thanks for your time on this project! Also thanks for making an effort to bring people together like this instead of just walking away unsatisfied.
As I’m reading @augier comments I’m trying to picture what may have gone fubar here. Communication is one of the hardest things for us humans, especially when we’re not able to read the 80% non-verbal part :wink:
I picture myself in a hurry and trying to coordinate some other people while I’m busy figuring out how I’d reach my own goals. I would probably try to say as much as needed with as little words as possible in the nicest manner I could think of in that hasty moment.

A solution to this problem of not having time to communicate as much as some would like is maybe to establish a communication-code where there is simply not enough room to say too much. So, maybe a twitter-like way with max 140 characters to provide feedback to a PR or ask a question. That way everybody knows they will get short and to-the-point answers and nobody will be offended by each other anymore. :slight_smile:

Github just leaves way too much space to chat and let conversations go haywire. Maybe it would already help to establish some agreement as to not discuss things but just provide short and informational feedback to each other (how would a computer solve this?)

Loomio, indeed, would be for discussing. But, when engaging in a discussion, you know you and others are taking time to elaborate their point of views so discussions will not go haywire that easily.

In short: keep github clean and informational without discussions, use Loomio and IRC for discussion and - when engaging - take time to discuss. :slight_smile:

Don’t know if this adds anything new or useful, but just my 2 cents here…

Most important, thanks all for developing! I’ll keep my pod alive and open to support the project.

@denschub, thank you for raising this topic, it actually shows that you care.

@augier, @loelo, @flaburgan stated some pretty good points that I agree with, and I won’t repeat them.

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.

That is definetely true and I beleive that I can participate to the base polishing as well. This is absolutely normal, when the base refactoring is done as a part of a feature implementation job. @supertux88 told me before, he doesn’t want me to write the code for the federation gem. I could, at least, participate to the testing, and I invested some amount of time into the federation testing automation job, which is unfinished yet, but could be extended and improved. I didn’t get any feedback on this, as I didn’t get any answers to many of my questions, possibly, because I’m considered to be an idling feature implementer, rather than a hard-working refactoring person. I’m ready to take some task that will help the refactoring process - if it is what blocks the migration project, then I’m interested in participating. I don’t know why, but there never was anything like a discussion of how to sync my work with the coredevs work. Looks like I was put to the low priority at the first place and never had a chance to discuss what is the best way I can spend my time on the project. It started from the very beginning, when I announced my crowdfunding intention to the core team in the middle of January. That’s very strange to me, because even if I’m not a coding superstar, I’m giving my resources to the project, and this looks like the coredevs are completely uninsterested in using my resources effectively.

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.

I may be wrong, but as I always thought the LOC number is quite a weak method of measuring the code quality, and DRY doesn’t have to reduce LOC significantly. DRY is about replacing special cases with common code, and building software the way when every important part has only one instance so that is simpler to change and maintain it in future. This was a small change, and I guess the fact it was small doesn’t make it useless. It was a code-styling improvement, and I changed that, because this part will have to be updated for the “mentions in comments” implementation.

As to your questions,

Do you feel comfortable with me doing the project maintenance? If no, who would be a better match for this role?

I guess no one will argue that you are doing extremely important job for the diaspora project. But there is no one who can replace you. While it’s possible to hire a usual developer, we can’t just ask someone to come and work as a project maintainer even if it was paid. The project maintainance is the job that requires good experience with a particular project. So if you go for any reason, that would probably mean the stagnation or decline of the diaspora project. So even if I’m uncomfortable to work with you, I have no choice. You have some privileges because of your experience and participation, but you shouldn’t use them to humiliate people.

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?

I don’t have a full picture of your work, so it’s hard to judge. I guess in the situation when you have only a few hours per week for the project you won’t spend it on something apparently unhelpful.

What would be the most comfortable and easiest option for you to learn what others are doing to avoid conflicts?

There were some ideas stated in other people’s posts. I like the ideas of online team board and IRC meetings.

However, if there is someone who is passionate about doing the communicating for me, I would be happy to collaborate.

What is required to do the communication for you? It would be a good solution actually, but the communication person must know the project state well, including who works on what and what are the project’s goals, resources, communitiy expectations, etc.

Thanks once again for raising this!

I have nothing but thanks to offer all the contributors and developers that have made diaspora what it is today. The development methodology that allows products to be created organically through a process of trial, error and feedback involving many people at the same time is powerful indeed. It relies heavily on communication of the right info to the right people at the right time, which is not always clear.

I wonder if it would make sense to have a ‘network of trust’ for the development. Contributors could push code to developers that trust them, who would then push it further to a core member who trusts them etc. It might help to make it clear who each person should communicate their goals and limitations to?

So it’s been a while since I contributed, but I had a good time doing it.
When I wanted to do something, I the first things I do is join the IRC and search existing issues to find clues on other people having the problem or already solutions as PR. Mostly I then ask about the thing I have in my mind in IRC and start talking about it.

Most of the time I have no clue where something is realized in the diaspora codebase. That’s the moment, when the IRC turns out to be a great thing - and you also are doing a great job. In these moments you (and Jonne and Steffen, so far) give me hints where to look and point me in the right directions.

I have no clue who is working on what and what are the big things that could / should be done before there is the next release. There is no overview chart (I know of) and I do not want to waste your time asking what the status is on every thing, if I just want to check to see how the status of the project is (I think you have enough to do already).

So having some quite automated roadmap / work-in-progress board would be quite nice (but that does not mean you have to implement / set it up, just in general). On this board there could be items for things that need to be done until the next release and items that are worked on… your suggestion of trello was not bad, but maybe more automated, because nobody in this community has the time to update something like that (recruit information from PR / Issues in github, let people manage their own things they want to do and automatically remind them after some time whether they are still on that, if there was no progress for some weeks).

I also read the comments here… I can understand some of the confusion about communication, but that’s nothing that can be helped in this comment section.

So overall I think the project is in good and able hands, a bit more overview and streamlined guides on “how to involve yourself and what to check before doing stuff and not waste your time” could be a nice help. Also: People should check IRC, everything is so much easier then.