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
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
