Hello Michael, Michael Brohl <michael.br...@ecomify.de> writes:
> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin: >> You are right. I should be more constructive than just acknowledging >> that the requirements I expressed were not properly considered. >> >> Let me try joining Pierre's effort by providing a simple but radical >> proposal for our contribution procedure : >> >> - Adopt Github Pull Request (PR) as the unique channel for code contribution > > -1 > > I don't see a reason why we should not allow patches also. It will > make it easier for people to contribute who are not able (or willing) > to run their own GitHub repository. > > We should encourage people to use PR's but not force it (at least, not > immediately...). The reason I see for requiring a unique code contribution channel is lowering cognitive overload for everyone. If a community ends up “requiring” certain contribution procedures that people are not forced to conform. It is then up to the reviewers to adapt or not to the choices made by the contributor. If you are willing to adapt and continue review patches attached to a ticket in parallel of the PR then those contributors will be happy. >> - Require tickets only for bug reports > > -1 > > Jira tickets for improvements/new features are extremely helpful to > have everything in one place (with the addition to a link to the > mailing list discussion), track the efforts, watch issues etc. > > How would you manage the work then? I think you misinterpreted the proposition, it is not because something is not required for every code contribution that it cannot happen when it matters, indeed in the case of long term efforts like for instance the “Groovy migration” it would make sense to have an issue associated with it, but for small code/documentation improvements having a ticket serves only a review medium which is far inferior than Github PR mechanism. So to “manage” stuff you could still use tickets and ML discussion like before, but it would just be done when necesarry not to follow the “everything as to be attached to JIRA” policy which was often justified by the fact that they serves in the Monthly reports. >> - Replace JIRA with Github issues > > -1 > > Why should we have two different issue management systems when we can > have everything in one place? What advantages do you see for doing so? > I also would not rely too heavily on GitHub because it is not an > official ASF resource and IMO Jira is a huge knowledge base of the > project. The advantage with Github issues is that they are well integrated with the Pull Request mechanism so it is easier to reference Github issues in PR (the reverse is also true). IME Jira does not help avoiding the “Cognitive overload” because its features are thought for the enteprise context with time tracked employee and managers producing reports to their superior which is far too burdensome to work with in the context of a community project. AFAIK the “everything in one place” you talk about is mostly fantasized and has never existed IME. People often have to cross reference parallel discussion happening on Jira and Mailing list. The adoption of Github PR in the contribution framework I am proposing will not improve that issue but at least it will not make it worse as it would be if OFBiz adopts Github PR as “yet another” contribution option ontop of existing ones. >> - Use Github API to get the stats for OFBiz monthly reports > > Can you elaborate what you mean/ how you would do it? I don't know and I don't want to know ;-). I am just aware that Github has a Web API which enables the retrieval of statistics on Issues/PR/Contributors/... which can be useful for satisfying the requirement of assisting the creation of monthly reports which some people in this community care about (full disclosure I don't). -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
