I was just reading about some fediverse tensions between a contributor and the project lead who are working on another platform. There might have been a way to prevent such a conflict.
Basically, the contributor was working on something, and the lead allegedly knew they were working on it, but decided to implement their own version instead of using the contributor's version (
i.e. their pull request). The contributor was obviously upset that they spent hours or even weeks on work that would never be included in the project. The first time it happened, it resulted in an apology. But then it happened again (and possibly other times), and now the accusations are flying.
I am not going to mention names or anything because it really is none of my business and I don't want to insert myself into something that does not concern me. But it did get me thinking about what could be done to prevent that from happening in projects that I am involved with.
Just off the top of my head, some things that could have prevented this:
- Have ways to override or enhance the core code by using methods like hooks, addons/plugins/modules, themes, widgets, etc.
- Have official discussion groups or forums where development discussions can take place.
- Make decisions together on:
- what is to be implemented in the core and what is to be implemented as an addon;
- what should be implemented as an official addon and what should be implemented as a third-party addon.
- Use git to manage code contributions.
- Use a project management system that makes it easier to manage decisions and coordinate contributions.
Numbers 2 and 5 should be fediverse-enabled, where possible.
Notice that this is more than just "we need to communicate better," which is great general advice. It is more about putting the structures in place that make it easier to collaborate. Even if there are disagreements between developers, it is still clear what the decisions are, and contributors still have the option of creating an addon if they can't get their code into the core.
And, for context, many features maintained by the core team can still be addons. Being an addon simply means that site administrators and developers can choose to use the official addon or use a third-party addon that does the same thing. And hooks can be used to override the default behavior of the core script.
For example, Hubzilla comes with an article addon that allows you to use Hubzilla as a blog. Since it is an addon, someone can implement their own version of that addon without changing any of the core code. If a contributor and the lead developer disagree on the direction of the articles addon, the contributor could fork the addon without forking the entire Hubzilla project, and then there would be two options for implementing articles.
In our case, Hubzilla already has Nos. 1, 2 and 4 in place (mods, forums, and git). Number 3 (decisions) is currently implemented in an unofficial way, but having No. 5 (project management) would make it easier to track and communicate No. 3 (decisions).
This is one of the many reasons why I am implementing a fediverse-enabled project management system (No. 5).
I can't force other people to use it, but for projects that I am involved in, at least I can track everything that is decided, and people have a place to go and see those decisions. If anyone wants to contribute or collaborate, I can point to something and say "this is what I am working on" so that it is transparent and there are less misunderstandings. And, ideally, I get them to use the same system.
