Hi Mathieu, Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
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.
I don't see any cognitive overload in having a choice between an accepted channel which is used for years and using a new tool.
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.
I don't see a need for a PR *and* a patch in parallel but would be happy to deal with either a patch or a PR as a reviewer and committer.
We should allow both ways and give people the choice how they want to contribute.
- 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.
Do you speak of the monthly blog posts?They are solely derived from the Git commit history, Jira is not used for it.
- 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).
The GitHub - Jira integration with PR's works fine so I cannot see this as a valid argument to switch the issue tracker.
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.
?! We don't use these features and therefore there is no burden introduced with them.
Are you really feeling challenged by the use of Jira?
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.
I don't understand why you need to use derogatory wording here. Strong words don't help and the fact that *you* don't like certain processes/tools/opinions does not mean that they are crap and not useful for others.
There is no contradiction in my statement. Discussion on the mailing lists are hold to reach a wider audience, elaborate an issue/topic and reach consensus. They should be referenced in the Jira where the work is tracked so that everything is in one place.
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 reportsCan 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).
This seems to be a misunderstanding as I explained above (if you talk about the monthly dev details for the blog).
As always, I'm happy to hear more opinions. Thanks, Michael Brohl ecomify GmbH - www.ecomify.de
smime.p7s
Description: S/MIME Cryptographic Signature
