openerp-community team mailing list archive

["Pieter J. Kersten" <p.j.kersten@xxxxxxxxxxx>]

For creating a library of functional complementary modules, it is 
necessary to assess each and every new module. It will raise the bar for 
newcomers. Then again, there is nothing against making a nice set of 
complementary modules. But it should not be mandatory.

Some advice: Make such module selection crowd based. Publish new modules 
or new ideas for new modules (from merges between modules?) and let the 
community vote. Then the reviewers and/or mergers will have something 
better to go on than just their own idea of reality. When new modules 
are delivered for the team, the original author can decide upfront if he 
or she is willing to participate in such a selection/merge process. 
Scrum based coordination is a natural partner for such a process (ideas 
as backlog, priority crowd selected).

Then again, what to do when an original author refuses to participate or 
bow for the crowd? Shut the doors? Throw it all away?
You can't cover all possibilities, but you have to cover the most probable.

'Nough said...
--
Pieter J. Kersten
EduSense B.V.

Op 23-11-12 15:26 schreef Houssine BAKKALI:
> Hi Jeff ,
>
> I'm not part of the reviewers, but I suppose that the initiave should 
> come first from the module owner. And in this case validated by the 
> reviewers... First in first served I would say then for the second 
> one... It should be discussed, comparing code quality, stability, 
> number of functionnalities... Then several choice are possible :
>
> - refuse the second one
> - accept the second one and drop the first module
> - decide to merge the 2 modules
>
> As I said this should be par of the discussion with the two authors 
> and the reviewers... With aim on quality, stability and so on...
>
> Yes, I'm not neither fan of the review process applied to the author 
> of the module... But as far as I undestood this process is also 
> applied if you're a reviewer...
>
> This should from my own opinion documented somewhere once all the 
> people agreed on the defined process that will applied to all 
> contributors...
>
> Houssine
> WebRep
>
> 2012/11/23 jeff.wang <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>
>
>     Housine,
>
>       Without a review for initial commited module, how to avoid
>     modules with same or similar module name in diffrent branch ?
>
>       say I have a module named sales_double_confirm in branch A, I am
>     the owner of this module and needn't been review before initial
>     commit.
>       you have another module named sales_double_validate in branch B,
>     You are owner of this module and needn't been review before
>     initial commit.
>
>      When an end user or consulting firm need a feature to enhance
>     sales order approve workflow, which module he should test ?
>
>      Now in apps.openerp.com <http://apps.openerp.com> or extra-addons
>     branch, many module have duplicate feature need merge in one,
>     isn't it one of the reason we need the new community organization ?
>
>      Forgive my English. I just want to say:
>
>       All commit or merge request to community branch need pass
>     through the review process, even when the author confidential with
>     his own work!
>
>       Cummunication over code.
>     ------------------
>     Jeff Wang
>     jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>
>     ---------------------
>     Maintainer of Open ERP china communiy
>     http://www.openerp-china.org
>
>
>
>     ------------------ Original ------------------
>     *From: * "Houssine BAKKALI"<houssine.bakkali@xxxxxxxxx
>     <mailto:houssine.bakkali@xxxxxxxxx>>;
>     *Date: * Thu, Nov 22, 2012 08:57 PM
>     *To: * "Pieter J. Kersten"<p.j.kersten@xxxxxxxxxxx
>     <mailto:p.j.kersten@xxxxxxxxxxx>>;
>     *Cc: * "OpenERP Community"<openerp-community@xxxxxxxxxxxxxxxxxxx
>     <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>>;
>     *Subject: * Re: [Openerp-community] New Community Organization for
>     OpenERP
>
>     I agree with Pieter. A contributor can't do worst than his first
>     contribution, which is his module, and can we block the access to
>     the owner of the module? He still has the intellectual property
>     and by this has the right to make his module evolve...
>
>     One different thing is to make a first review on the module at the
>     time he propose it for MP...
>
>     Accepting a module and accepting modifications on it could be two
>     different validation processes... no?
>
>     my two contribution,
>
>     Houssine
>
>     2012/11/22 Pieter J. Kersten <p.j.kersten@xxxxxxxxxxx
>     <mailto:p.j.kersten@xxxxxxxxxxx>>
>
>         hat's the way OS has proved to work over the last few decades.