I don’t believe a hard set rule is the right way to go but I would say something like “standard should only contains generic modules”.
This reasoning could be applied also to account_statment_*, OK sepa could stay from my pov, but do we need ofx or mt940 because we can do it?
Having a large library of module is nice but going too big might be counterproductive.
I do, there has been time and again discussions about features that should be included in the localization modules but were not generic enough or not good enough. This decision would end those. The local community deems a change to be required for the correct handling of the accounting in their country: so be it!
A new module should be discussed here and we can probably reach a consensus about the place of the module.
Of course it might happen that a module in contrib is so good that can become part of standard. But I would guess that it won’t happen often.
Indeed people might make error when reporting bugs. It’s an issue that people maintaining backports for distributions (such as @yangoon (if you could give us your input)) probably had to tackle already. My bet is that it’s not a big deal.
Also keeping the backports in standard would in some way put an official stamp on the backport while in my mind it’s provided as a best effort only.
Indeed as @Dan and @sergyo said there are not much incentives for people to use contrib when they already have a code hosting solution.
Still we can hope that it will be a central place where people contribute together on some common needs instead of developing for the 4th time a module implementing the same behaviour.
Frankly, I don’t expect the contrib subgroup to be a success (it’s probably too late for this). But it’s worth giving it a shot.
It was hard for me to get an opinion on this topic. For a long time it was my desire to have such a repository collection. We tried it many times on origo, google code, bitbucket but always failed to maintain a separate fork.
I share your opinion. My first impression was similar as @Dan and @sergyo: Who will change/fork the own CVS and routines?
As we decided, to also move to heptapod this is now answered for me: For us it would be easier to contribute and collaborate with such a repository.
I like the idea in a way, because it addresses some problems in the project:
Maintenance of the ecosystem is too much work for the maintainer(s) and contributions to the project are taking too long time and becoming very costly for the contributor. On the other hand I am can’t imagine how to find a happy medium between over regulation and bad quality.
I like the ideas to use the CI for a basic quality control and the readthedocs integration for documentation.
The ecosystem integration of modules is a topic where I am a bit clueless. For now modules provided by the Tryton Project are playing well together. We can install what we want, everything integrates to each other, beautiful. This is very valuable but also very elaborate and hard to gain. For now we gain this quality with a restrictive gate keeping and the last decision of @ced.
When I compare with our predecessing project, they have a module-central from the beginning with thousands of modules in very varying qualities and different integration levels. They exchanged the problem of not having a module central and supporting collaboration, to a knowledge problem:
knowing which modules are good and
which modules are playing together.
It is sure for me, with a contrib repository we will get modules, which don’t integrate to each other, because they come from different vendors. Also there may be modules which don’t play together and break each other. Such a repository will harm the high quality reputation of Tryton, because when something is provided by the Tryton Project, it is the Tryton Project. But I think with a clear communication we can avoid most reputation loss.
But maybe all these new problems would be better problems. Because they are easier to solve: A contrib repository is more attractive and accessible for non-programming people. It is a much lower entry barrier to collaborate, when there is already a functionality. Talking about an issue is much easier then writing a blue print and code a module. Also building knowledge and learn about the contrib modules quality and how they play with each other is a way for non-programming people to find a better entry into the project.
Rethinlink this, a single repo might be easier to maintain: Run the „update to next version“ script for all modules at once, create a merge-request for each module and merge those packages passing CI. This could even be automated.
this depends on the answer to the question “Who is in responsibility to maintain a repository?”
IMHO if a single person or group maintains the complete contrib-repository-collection it is easier to maintain a single repo. If every repository is maintained by another person, separated repos seems better to maintain. Authors can also provide a single repos for all their modules.
I hope so but I think what should change is the general relationship of the de-facto contrib publishers with their potential contributors. And I mean both ways.
Sometimes, contrib material feels too bad quality or even total abandonware to the extent that introducing such dependencies in my organization is considered a bigger liability than re-developing something from scratch. Then it could be argued it would be wiser (and it is) to contribute back and build a better common resource. But the fact is some contrib publishers just accidentally use GPL-3 and community contributions have no viable upstream path (e.g. an open MR will be ignored forever)
Moving all this into a centralized contrib subgroup will not solve this issues. But maybe it would alleviate them: now I wonder how an abandoned project would be dealt with? E.g I had to vendor the abandoned fio_sale_line_warehouse · PyPI . What pypi owner would be the actual publisher of contrib modules? Could the Tryton supergroup transfer contrib repository rights to new volunteers if former maintainers vanished?
My question was about transferability of the heptapod repository within the contrib subgroup. Thinking about it, I imagine being under the Tryton supergroup implies the Tryton organization would keep some ownership over contrib repos so designating new maintainers would always be an option.
What you linked was a sensible follow-up depending on the answer to who would the PyPI project owner be. But now I am bit puzzled about @ced’s comment stating contrib modules would not be published to PyPI at all.
This discussion is stale since two month now. I’d appreciate to come to a solution and to get the contrib repo(s) up and runing. I suggest deciding on a solution at the Unconference.
My answer to this question: “The community” — this will either work if there is a community interested in this repo or fail, if there is not.
Who is the community? I think we should get at least some names that will be interested on joining efforts on such repositories. I guess you will be interested on it, but who else?
To move forward on this topic, I think we should not wait to have any kind of statutes or rules for such subgroup In the same way Tryton was started, we should just act and solve organizational issues when they appear (we have a Foundation to take decisions when needed).
So I propose to create a subgroup “contrib” on Heptapod inside which anyone can request to the Foundation to have a project. The request will be evaluated by the Foundation based on the description of the requester like goals, targets, pertinence etc.
Similar to the translation organisation, the requester will have the administration right on his project and will be able to invite others, activate services etc.
I do not think acting without consesious is the way to go in a community project.
There has been 5 months since the start of this discussion and there it just happened one months till the organization of such project started in the Tryton Unconference, so I do not think there is any rush to move this forward.
I have talked with @htgoebel (who is now in holidays) and he has been working on a proposal for rules and defining the organization of contribution modules in the discussion pad.
There has been so much work done which should not be ignored by just going forward without consciencios.
This is your proposal, but as there are other proposals we should not do anything unless there is any agreement on the community.
The foundation is discussing about this topic (i started the discussion this morning) so at some point is already taking a decision on it. We should wait for an oficial statement of the foundation before doing any action.
But this is working in a community, working alone does not scale and we need to discuss and reach agreements.
TBH: I’m also tired with some contribution process that take IMHO too long. But that is open source and working towards having a better quality code.
This is not what has been agreed on in the workshop at the TUB23 (which you attended). And this also does not meet the aims agreed on at that workshop.
Also this proposal leaves open, how will be “the foundation” that decides? Given that even six weeks after the TUB23 “the foundation” did not even give a statement whether they support this idea or not: How long are requestors expected to wait for an decision?
If the board supports tryton-contrib, IHMO a statement of the board is essential to show it cares (as opposed to “don’t care” (aka “we don’t give a shit whether there is some contrib or not”)). Being the president of a club I just learn, that it is essential of those in charge to “care”, which will motivate others to do the work If the president/board does not show interest (aka “cares”) others will just be demotivated. And the way an organ of a organization shows interest is by bringing about a formal decision — which IMHP is overdue.
If the president/board does not show interest (aka “cares”) others will just be demotivated. And the way an organ of a organization shows interest is by bringing about a formal decision — which IMHP is overdue.