| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Alexandre, Of course you are free to disagree. Allow me to make a few remarks though:The sole reason someone *can* share code, is because it was written, used by and payed for by someone who apparently cared and was happy with it. Your whole idea of "unwilling" and/or "uncaring" authors is therefore IMO unfounded. When authors loose interest over time (and most will), you can always ask the author to transfer it to you or else render it "abandoned" or something like that.
The sole reason the addons community exists, is because several authors decided long ago to change and extend the default behavior of OpenERP's core modules and OpenERP refused to take these changes/new modules into their core. With good reason from their perspective. The several authors took the liberty (and obligation) to share their code. Others used this code yet again and enhanced and extended it. See, a thriving community.
When new authors dive up with their modules and you refuse their contributions based on a presumed quality standard, you risk them feeling disrespected - you are not the only proud professional out there - which can ignite a repeat of the split process which led to this community. That would be a loss.
Your idea of quality is your (professional) opinion. Nothing less, nothing more. You can earn credits when others see viability in your opinion and act accordingly. It is however always the choice of others to do something with your opinion - or not. No single opinion, by any individual or group, should block viable contributions to Open Source. And by "viable" I mean as seen from the authors perspective.
The whole concept of Open Source is find it, use it, enhance/extend it, (re)share it. And when nothing is to be found: build it, share it, foster it. Your use cases assume economic viability from the perspective of the reviewers and seen as shrink-wrap software. But viability is in the eye of the beholder. No-one can predict other users needs searching for perhaps the same functionality you refused. And Open Source is not equivalent to shrink-wrap software.
In case 4, when code was shared but not up to your standards/ideas of viability, the author doesn't respond to your summoning and someone steps in and "takes" the module, it is effectively being hijacked. If "Alan" receives credits for doing that, then when the original author returns, he will find "Alan" on his path blocking his way, backed by the group that gave him the credits. That's plainly unethical by all standards I know of.
I concur that co-operation can achieve benefits for all. But for that you need to be open for all. I see need for coordination and quality assurance by original authors, and if the now chosen reviewers are willing to assist in that - splendid. In co-operation with the authors, you can reach an accepted flow and set of standard for certain modules and perhaps even a base standard for the set of modules as kept under the umbrella of gathered modules. But that's as far as you can go. Any new module will bring its own standard, which should open up the discussion. And there is nothing wrong with that.
The points of view you share, breath an intent to become *the* source of community modules and quality standards. That can be achieved within a closed environment as can be found within a company. But out in the open that would require world domination. And that would be pure arrogance. No-one looses credits for sharing code. But a community with domination intents will. It would simply create another single point of controlled publication of OpenERP modules, next to OpenERP's core modules, giving credits to the reviewers, but achieving that by ignoring the base concepts of Open Source. Yet another "partner"-model in the making. But with that intent, not one I would be happy to be a part of. It would harm my credits if I would.
I sincerely hope the community to be wiser than that."If I would dictate my worldview upon others, I would be plainly disrespectful. But in order to do be able to keep mine, I have to dictate others to respect others' worldviews."
Just my 2c. -- Pieter J. Kersten EduSense B.V. Op 22-11-12 14:12 schreef Alexandre Fayolle:
On jeu. 22 nov. 2012 13:33:06 CET, Pieter J. Kersten wrote:You still miss my point. It is not in the behavior of the reviewers I foresee impoliteness, but in the fact that someone contributing a new module and making enhancements to his own module, is forced to convince a tribune of reviewers of the quality of this new contribution. The flow can become: refuse it, refuse it, refuse it and then, when the quality is "high" enough - who says what's quality and what's high enough? - take it. Phew, it's in. You risk bashing people away by enforcing the mechanics alone. A "politer" flow would be: take it, grant the author access to it, review it and then, if that "proves" to be necessary (for you?), enhance it in co-creation with the author. No sweat, everybody happy. That's the way OS has proved to work over the last few decades.I beg to disagree. What the politer version leads to in my experience is tons of non maintained modules which were checked in once in the past and slowly decay over time (extra-addons is full of these). This is *not* the way you will ever get a new piece of code in major OS projects such as Gnome, KDE, the Linux Kernel, or include a new package in the Debian distribution. Let us take an example. John Doe wishes to add a new addon in team maintained someproject-addons. He pushes his branch with his new module on launchpad and proposes that the branch is merged. It should not matter if John is already a member of the team or not. Case 1 (dysfunctional) : nobody cares, no reviews are given, positive or negative. John should ping people a bit. If he is already a member of the team, after some reasonable time and warnings he may force the merge. If not John will have to find another place for his addon, and he will earn the right to criticize the community. Case 2: John's module is super specific, super specialized, and people reading the code say so in their reviews. There is discussion, and a consensus is reached saying that the code does not belong to the projet and suggesting to John that he should find another project for his addon, and thanking him for his contribution. Case 3: John's code is poor (e.g. there are no comments, no the few help strings are written in very bad english, and some algorithms are not efficient). This is pointed out in the reviews, with fix suggestions. John is unresponsive to the suggestions and does not apply the various suggestions. Nobody is really interested in maintaining the new addon, and since John is obviously not interested either, the MP is rejected. John's credit is harmed. Case 4: same as Case 3, but Alan steps in and mentions his interest in the addon, and applies the fixes, and overall commits to maintaining the addon. The MP is applied. Alan earns credit. Case 5 (hopefully nominal): The code is OK, within a few days, the MP gets a couple of 'approved' reviews. The merge is processed and life goes on. John earns credit. Compare to Case 6: Same as case 3. The merge is performed, hoping that this will encourage John to fix the issues. John is never heard of again. No one in the team uses the code, so no one feels committed to apply the fixes. However, some people outside the team install the module in production. They submit bug reports which no one feels inclined to process because, well the code is crappy in the first place and should be rewritten, and no one really has time to fix the issues. The team looses credit, and the members morale is harmed. Who says what "good quality" is and what is "high enough" ? We do. How do we now ? Because we are programmers, and we have seen bad code and we have seen good code, and we know how to turn bad into good. We can help newcomers improve their code (and, yes, we can do this politely). But it is not helpful to anyone, neither to the author of low quality code, nor the the team in charge of maintaining the code base, to accept low quality code in the first place, and to leave the team in charge for fixing it. Known issue must be fixed as soon as possible (and if possible before they are merged). -- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 94 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com
| Thread Previous • Date Previous • Date Next • Thread Next |
