Collaborative Hosting Of High Values Addons/gems for Decidim

[microstudi]

I'm starting this discussion in order to se if we can figure out a (simple) set of rules that we all agree for dealing non official modules for Decidim. Non-official modules are usually created by the companies providing service to final clients that want some tweaks or custom behavior out of their Decidim instance. This is great as it generates value around Decidim and promotes diversity.

However, we've identified a set of problems with the current approach were each company creates their own product (or module), usually thanks to the funding of a sole client. The need to have a community-based approach is due the fact that many other organizations can and want to benefit from those plugins.

Current problems will be (please amend this in the comments):

1. Unreliable maintenance: Some companies might create plugins but their priorities change or they don't have enough time/resources after a while. This ends with plugins unmaintained or with bugs in the long term. The main problem here is when a useful plugin is being upgrade/maintained/fixed by a third party who needs it (ie to adapt it to a new Decidim release), creates a PR to the original author and this is missing or unresponsive. This is a bad situation for all the actors involved as gives the impression of a fragile ecosystem and a lack of commitment.
2. Gems maintenance: For similar reasons, the maintenance of gems hosted in rubygems.org is often outdated and does not follow development in Github. This forces to use custom Github repositories with custom branches, increasing fragmentation and, many times creating duplication work because it's hard to know where is the most recent release.
3. Feature/Bugfix funding: Usually funding a feature requires some client to pay for it. Bugfixes might have a more voluntary approach. In many cases however, a stronger collaboration between companies can lead to cross-funding certain features, which will improve the quality and maintenance of plugins.

As a quick list of examples of stalled PRs in popular plugins we see for instance:

• Upgrade to Decidim 0.26 alabs/decidim-module-calendar#37
• https://github.com/Platoniq/decidim-module-decidim_awesome/pull/191
• Upgrade to Decidim 0.25 coopdevs/decidim-module-action_delegator#117
• Improve setup documentation. Add ENV vars for easier configuration Platoniq/decidim-module-civicrm#26

One solution proposed to improve this situation, is to have a central organization where to host all of these high value plugins. The main point of this approach would be to have a shared authority on the hosted plugins. This way, if a developer abandons some plugin it can be assigned to another maintainer. Of course that, for this to happen, the original developer/company must agree with a set of rules that permits this organization to do that. And, for that, we should discuss which are the rules for a healthy community of plugins around Decidim.

• We will leave the discussion open until December 4. On behalf of Pokecode, we will campaign with those organizations that have not joined at the moment, but have interesting modules.
• With the inputs we receive, Pokecode will write a "manifesto" (if there is another volunteer, please take the initiative!)
• we expect to work on this manifesto for 1-2 weeks, with any other organizations that are interested, it will be a draft. Maybe we can take advantage of the meeting Francesco is organizing.
• After approving of the manifesto, the organizations can start moving/copying their modules in the organization.
• Each organization that has a module will have the right to have a vote on the board, although more than one person can come. Even if there are votes, we are based on trust and credibility. In this meeting we can talk in more detail about the collective maintenance strategy this can be discussed

[basicavisual]

hello Ivan, I agree. I also wanna sign up to the bugfix party. the examples of stalled PRs you propose are also fine by me. I can start checking the alabs calendar module.

[microstudi]

Well the point here is not to see who can do what (although it is fantastic to have this spirit!) but to create a common space to host plugins. Take into account that the problem with those PR is not that they need help in finishing them, is that the company behind is not responding/reviewing/merging them and we have no power over it.

We, as PokeCode, are ready to move all of our plugins here and also share ownership of the rubygems repositories. We'd love to know who else is willing to do the same and under what conditions (therefore the need for these rules)

[PierreMesure]

Super cool if we can have shared ownership of some modules and more collaboration on maintaining them!

I think moving them to a common organisation on Github is an interesting idea. But can't we just fork the old outdated modules instead? And update the forks?

[microstudi]

To me, fork or not fork is not really important. What matters is that in here we should have the latest version of the plugin, set it as the "official place". It also should be accompanied by a shared owner ship of the corresponding gem in rubygems

[Quentinchampenois]

Hello, I agree this is a good suggestion !
Also I see an interesting point (maybe this is not the right discussion), but it could allows to define some rules / guideline to have more homogeneous modules.

I explain, community modules are not always simple for contribution since there is no coding style pre-defined. Also, I think it could be interesting to have a documentation for :

• Choose between an Extend or Override (what are advantages / inconvenients)
• How to deal with versions dependencies
• Define common tasks like installing Webpacker resources, migrations or others (at the moment we must check on every module what are the required commands to execute to make it works)

[paulinebessoles]

I would also add those kind of rules:

• Clear documentation on how to install and contribute to the module
• Having to publish it on Crowdin and update the translations regularly

[microstudi]

Looks like we will have two levels of rules:

• A manifesto for inter-collaboration, defining mostly the co-ownership and trust between members
• A practical recipe for maintaining/creating modules that can be hosted in this repository

[PierreMesure]

It'd be great to have some support regarding Crowdin, and maybe be able to do it from one common paid account for all the gems? I tried to do it for our modules a couple of years ago and I think it was possible to apply for a free plan for OSS but I failed and since then, I get a banner saying my trial has ended 😁.

[paulinebessoles]

I agree, I tried to do the same but it didn't work. I contributed once to the Matomo translations, and they use the Weblate tool, with the Matomo core and all the plugins: https://hosted.weblate.org/projects/matomo/
Maybe we could dig into that? And ask the Association if that's something that could be relevant for them to, to have all translations around Decidim in the same place?

[SimonMulquin]

Hi @paulinebessoles, I actually had a great experience using weblate and proposed it to decidim during the internationalization workshop.

I see it as the best alternative for open and continuous translation, giving the opportunity to any non tech translator in the world to open decidim inside their communities.

A question was left to think about: is it of any use regarding decidim's currently well developed translator community and if not, could it be the free alternative for providers to implement quality translation on the end user generated content since this part is currently not implemented in decidim.

I am interested in discussing and challenging furthermore the importance of internationalization in the development process :-)

[paarals]

An important aspect is to make the financiers of this module visible, even though ourselves if we contribute without external financing. I believe we must be concerned with the effort made by these organizations in favor of the global decidim and recognised. I think that it is a transparent mechanism and it gives relevance to the co-financing of open source

[froger]

@microstudi Thanks for the well documented proposal! I have some questions before reacting ;)

Each organization that has a module will have the right to have a vote on the board, although more than one person can come

Just to check: I understand you talk about governance for gem management: who bring repos help the gems and takes part to decision. And not about an actual DICE board who takes decisions over the whole group. Is it right?

After approving of the manifesto, the organizations can start moving/copying their modules in the organization.

I understand here that the manifesto will be the reference for decision. Does it mean that the "board vote" you talk earlier is a veto kind of vote?

Thanks,

[froger]

thanks @alecslupu for bringing some ideas!

I realized I wasn't clear with my question: I want to ear from @microstudi about these aspects of the proposal. 🕊

This way I'll bring comfortably my suggestions as well. NB: I am quiet ok with the proposal, but need to understand it better to "fork" the proposal

[microstudi]

Actually I was restraining myself from proposing an initial set of rules because I wanted to hear about what others think. I'm with @alecslupu in the spirit of what these rules should be:

1. you maintain the ownership of your module, the fact that you are giving permissions to this "board" is just for the case you are unavailable or unreachable for some reason and for a minimum period of time. We should define what "unreachable", "unavailable" and the "unresponsive period of time" should be.
2. So, this board will act only in this scenario, then their task will be just to appoint another responsible for the module and the publication of the "abandoned" gem.

Another think is the rest of decisions we should take, for instance "what modules should we accept", as Alecs is starting to discuss. In my opinion, we all should have a vote on this. For instance, someone that wants to propose a module to be included in here, should specify:

• Why? the relevance of the module
• Who? who is the initial maintainer
• How? Does it fit to our criteria of quality?

With this information we can vote on the subject if necessary (or simply accept it as it fulfills the rules)

[froger]

Great, thanks! That's much clearer.
My reflection on this is then:

• Loved the idea about unavailable/unresponsive, that makes perfect sense
• The manifesto should not be related to decision, but more a guide for PR/moves for the plugins.
• Who does the job decide: I would prefer to have a group of contributors that can evaluate and decide without having a one vote for all. It will be faster and more fair in my point of view. I mean by contribution: code/doc/co-financing
• I would prefer a system of "objections" over a "vote". This "group" of contributors will evaluate: does it makes any harm to add this module?
• I would feel confortable not being in this group of contributors, and join as soon as I get a repo accepted.
• The "ownership" of the gem once it goes in DICE is not clear to me. If we decide to have all module ready for 0.26.3, the owner is accountable to upgrade ASAP? I think the proposal should includes something like that.

Hope it helps somehow in designing a proposal ;)

[tramuntanal]

Great work @microstudi and thanks for the initiative,

I would like to add some other points:

• I'm not totally sure but I think that some operations on the projects depend on Organization permissions. This will mean that the owner of a module depends on the Organization. Being said that, I understand that any organization with a module in d-ice will have administration permissions for d-ice?
• Imagine we, CodiTramuntana, develop a new module that think is perfect to be added to d-ice. But there is an acceptance process that should be accepted first. There is the risk that:
  • some accepted members of the board with vote right are unresponsive. This should be taken into account
  • the acceptance period takes a long period. Should we restrict to a couple of weeks and automatically accept modules from members if in a 2 week period nobody raises finger? I understand that accepting modules from non members should be more cautious.
• Accepting a module would mean that somebody from d-ice should be added to the the gem in rubygems.org no?
• Some quality minimums for the gems should be required: well documented at least at the README, CI with a good test suite

answering @froger question about

The "ownership" of the gem once it goes in DICE is not clear to me. If we decide to have all module ready for 0.26.3, the owner is accountable to upgrade ASAP? I think the proposal should includes something like that.

My point of view is that this is just the idea of d-ice, as many modules may start with funding but then funding disappear, the maintainer does not have the obligation to keep maintaining the module but being in d-ice some other member that has interest to upgrade (or improve also? -open question-) is free to upgrade the module or review & accept a PR from an external collaborator.

[microstudi]

I think that the idea would be to have a set of points that, if you comply with them, it will take only one or two administrator to accept it. Criteria should include quality and commitment from the author in order to be responsive, or maybe anyone proposing a new module should come with a "second chair" developer to ensure redundancy. And why not, to me anyone actively taking care of a module should be the organization owner too if necessary, this should be a very trustable environment.
In any case, if a member of a board is unresponsive then it should be removed from that position, we should have rules for that too.

All of these contribution are very welcomed, they are going to be the base for the manifesto, we will propose it soon and then we all can make amendments (:thinking: rings me a bell...) to it.

[sseerrggii]

I like the idea @microstudi For me it's like have a community maintained Addons/gems for Decidim

Also will be easier to choose when you are looking for Addons/gems, it''s kind of guaranty that this code will be supported long term

[microstudi]

Yes indeed, I think we can be like https://thephpleague.com/ in the long run