Mathieu, Michael, all, Please try to keep an open mind.... Sticking to own dictats about one or the other set of 'rules' and tools is not helping this project.
It is better to find a compromise that works best (or is least restrictive) for all, seasoned contributors (whether privileged or not) and others. Neither does expressing perjorative sentiments. Neither derogatory wording, nor strong words were used in the section where it hinted to. As for PMC Members claiming that the Github services (repositories etc.) are not *official* ASF tools, I suggest these persons stop this kind of FUD (and maybe check back with the ASF). Several project have only Github tools as above-the-line services working for them. And the INFRA ensuring that, with below-the-line services, everything is retained within the ASF architecture and infrastructure. Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Wed, Mar 11, 2020 at 10:01 PM Michael Brohl <michael.br...@ecomify.de> wrote: > 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 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). > > 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 > > > >
