We had a brief discussion on the foundation about the topic. Here is the summary of the opinions:
It will be great to have a more concrete proposal before the foundation can make an official statement.
None of the foundation board raised any concern against the contrib organization.
On the other hand, some board member literally said: " I think it is important that the contrib idea move forward".
I will express my opinion as president of the foundation. I think it is important that the tryton community moves forward to a proposal about contrib modules. This proposal should be worked by the community members so it fullfills all of their needs. I think It is also important that a contrib project is started from the roots and move forward by the community members.
So please, go forward and make the tryton contrib project a success! Once the project is started I guess others may join (I will love to do so and it is on my plan). What I’m sure is that waiting will just not produce anything.
As president I’m interested on the contrib modules, so I do not see any reason that will make others demotivated
@pokoli Thanks for this clear statement. This sounds good to me and is motivating. I fully understand the board needs a proposal it can decide on. Given this statement I’m pushing forward to finish the proposal
I think this will be the main danger by accepting any kind of Tryton modules.
And I will not like to have under the umbrella of the project such bad quality.
Also another danger is that there will be no real incentive to try to have a module or a feature in the Tryton core. This means that instead of working and discussing harder to have a generic solution, we will have hundred of easy custom (and incompatible) solutions.
And finally vertical solution based on Tryton (like GNUHealth) would deserve their own project. So they are out of topic.
So for me we should not accept to host Tryton modules that are not in the core but we need a place to host side project like the filestore, logger or other framework libraries.
What will be the minum requirements that you will like to have to accept them under the umbrella of the project? It will be great to share your tougths there so we may consider adding them as part of the Tryton rules.
The number of new modules added by external contributors ( non maintainers) cleary shows that the incentive is not working now. Mainly the point of contrib module is to reduce the effort to share a module while do not reducing the benefits, so more people can join the shared efforts.
That’s already the case because people are just implementing the solutions on their own when failing to contribute them to Tryton. And this is something that I expect to be fixed with contrib modules. Having a more flexible rules will allow more people to contribute and work together in a more generic solution that works for all. Once they are shared in a common space is the work of the contributors to make it comptabile between each others and improve them step by step.
Main problem now is that is nearly impossible to add a new module to Tryton core to anyone except B2CK. So everyone is just creating their modules on their own and not sharing efforts.
To host such projects we can just use a subgroup like you proposed: Move some repositories to subgroup
To be honest, my main interest is in a place to share modules which are not accepted as core modules. Which currently do not have any place. And this place should be tryton-contrib.
The same as core module but so why not add them in core module.
I do not think the number of module is the right measurement, it is the contribution.
Reduce the quality is my main concern because even if it is stated somewhere that it is not at the quality standard of the project, people will not read or understand it.
(We can see how often we got questions about GNU Health here in the wrong place)
That’s up to them. We can not force people to contribute, especially if they do not want to contribute within the Tryton standard.
Than this is not Tryton. This can be done elsewhere.
This is not true.
And before adding new module, try first to fix and improve existing.
I do not see why Tryton should accept modules that do not follow the Tryton standard.
You can share your module wherever you want.
Also often it is stated that there is no goal to make such “contrib” module to the core. So I do not see how this is helping Tryton if at the end we still not have a generic solution to a problem into the core.
Because the community wants a place to share more flexible rules, lower quality and non generic modules. Not everything should be in core, or yes?
Please open your eyes! Let me know the last module that has been added to Tryton without any intervention of B2CK.
I’ve been doing for ten years already.
This is the main point of the topic. Have a common place where anyone can share their modules and anyone can work together
I already had the idea for the very behining and I explained already on that topic. Contrib module can be used as incubator module and latter evolve it as generic solution to add them on core. Or we may even just complete the core modules to implement more concrete proplems or rejected featuers.
Who is “the community”. At least it does not include me.
If some people wants a place with lower quality, they can create such place. I do not see why the Foundation should spend its limited resource to support that.
It does not work as it has already been tested.
If the development is not discussed following Tryton processes, it does not succeed for inclusion.
Of course not, because you are the project leader and who mainly decided the current rules.
It is clear that there is people not happy with the current rules, otherwise we will have never been discussing anything in this topic and having a dedicated workshop in the Berlin Unconference.
If you are looking for exact names, I think there are enough examples on this topic but I’m sure it is not limited to people who showed interest on this topic.
Because the aim of the foundation is to support community activities. And this is not just limited to core modules as the comunity is bigger than just the Tryton maintainers.
That does not mean that one can share some code on contrib module and this can be picked as base for the dicussion. But I do no think we should limit the powers of the contrib modules. One can be free to share whatever their want and if it is enought interest the maintainers can organize themself to fill the module for inclusion. Even if they do not land on tryton, if the module it is improved we gained something.
Quality can not be achieved as a single step. So the incubator will be a good place to release working modules, get feedback and improve it step by step.
About the incubator chimera, it never happens (except for very few counter example). There are many “contrib” project out there and any were ever submitted to the core:
Of course many are more for a vertical solution (and so they should not be part of core) but some could be.
Why it does not happen, I’m pretty sure it is because they do not want to change their solution for a generic design because it means having to do a migration etc. This cost too much for them then the benefit of the community support.
This is why I always urge people who wants to make a module for core to first start with a blueprint.
So such low quality “contrib” project will not become an incubator, just like all those projects did not.
I think all those modules should be part of a contrib section. One will expect to find more vertical solutions over contrib modules.
Event if they start a blueprint, that does not mean it will land for core. So contrib module should welcome all of the work that should not be part of core.
Becoming an incubator is just an option and not the main objective of contrib modules but can be a side effect.
This is the goal defined on the first topic of this post.
And also having low quality modules is not also one of the goals:
Furthermore, the fact that the contrib modules are part of the community modules and are promoted by Tryton will provide a single place of colaboration where anyone can colaborate. Having several separate places with different rules just make it more complex. So contrib repositories is the only way to improve the situation.
Another idea I had about contrib modules is that it should follow as much as possible the core development workflow, rules and structure. This way, one can collaborate the same way on any of the repositories. If we follow this, contrib should also improve main repositories contributions.
Indeed what is repeated often is that the issue is custom modules are developed but others do not know about them nor could not find them.
So for me the most generic solution to this problem is to provide a listing (not a curated list like Third Party Modules - Tryton Discussion) of all known third party modules (like https://djangopackages.org/).
This is why I proposed Third Party Modules Listing Website
