As a Maven user experiencing finding issue tracker recently[1][2], here are my two coins:
1. GitHub Issues help to get issues reported at the exact code repo. I found a usage question for ASF parent pom and find the code repo at[3], no GitHub Issues and I jump to the linked JIRA project MPOM, while the maintainer tells me it's not the correct place. I'm familiar with the mailing list way so it's not quite a trouble to ask here. But as time goes on, more and more developers and users get used to the GitHub platform. No matter if it's a good thing, it's a fact[4]. So, for lowering the bar for user participation, I agree we can give GH issues and GH discussions a try. 2. GitHub is a proprietary service that is unreliable in an organization's view. I agree. Part of them can be resolved by we sync all traffic back to an ASF mailing list, like most of the ASF projects I participated in[5]. We can thus archive most of the context but since they are for archiving only, the readability can be bad. To sum up, as new generation developers and users grow and they are more familiar with the GitHub platform, before we find a competitor to compare with, and since we can more or less sync the conversation back to ASF INFRA, I'm +1 for giving GH issue and GH discussion a chance. But, in the other hand, if we can link the JIRA project and the code repo properly, given that our mailing list's and JIRA's responsiveness is high, it's good enough for me that we use GH PR for the patching process only, keep issues on JIRA and make most significant discussion on the mailing list only. While, GH discussions is a net win as a user forum just like a stack overflow tag - we can ensure no development decision is made there and everything is back to the mailing list. Best, tison. [1] https://issues.apache.org/jira/browse/MPOM-418 [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln [3] https://github.com/apache/maven-apache-parent [4] https://www.goodreads.com/en/book/show/54140556 [5] https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88 Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道： > Howdy, > > I do agree with Lukasz here...but > > In general, my intention with bringing up this on Slack was motivated by > following reasons: > - we do have ML (signup needed), > - we do have JIRA (ask + approval + signup needed), > > But all this is a high barrier for "one off" users, many of our users want > to ASK us about something, so going through hoops and loops above (and > coming back 2 yr after with "please unsub me...") only to post a question > is just a very bad experience. > > Moreover, we are very fragmented repository-wide, and I bet that a novice > user will simply be lost: > - WHERE (as in which Maven-* GH repo) to ask > - WHERE (as in which Maven-* GH repo) to report issue > - etc > > This is why I recommended "single entry point", a kind of dispatcher > (discussion) repo/GH project, where one off users can hop on, ASK things > and disappear if they like, receive answers where to go, and so on. And if > they feel like it, they could join ML or register to JIRA, something TODAY > EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers" > would not go so far even. > > For me, most reasonable would be a new "discussion only" project, for > example "apache/maven-project" on GH, that would contain no source, no > issues, only discussions enabled and would serve as a "low barrier lobby" > for newcomers. > > Opening discussions in _existing repository_ is unwise IMHO, as "general" > discussions/questions do not belong to apache/maven, nor > apache/maven-clean-plugin, nor any other existing repo. > > Thanks > T > > On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <l...@code-house.org> > wrote: > > > I have no strong feelings, however relying too much on single service > > vendor is never a good idea. In this case if one day, by some > > terms&condition changes, github repos are not an option any more, we are > > fine with ASF infrastructure. But we can't do same thing for issues > > which are embedded in GH database. If you ever found a google code > > project migrated into github/gitlab issues you know what I mean. > > > > While policies imposed on JIRA account creation, are without doubt a > > bearer to contribute first bug report, JIRA itself helps us keeping all > > ASF information together. Just to be clear - I keep being lost with new > > JIRA user interface, I'm just reflecting my personal thoughts. > > > > Best, > > Łukasz > > > > On 27.05.2023 09:30, Hervé Boutemy wrote: > > > Le vendredi 26 mai 2023, 19:41:53 CEST Benjamin Marwell a écrit : > > >> Big +1, as more and more projects are already migrating (including > > Apache > > >> Shiro). > > >> > > >> I'd vote for maven-jlink-plugin: Not many issues currently. > > >> > > >>> not having to create an issue if a PR exists first > > >> > > >> I'd at least make milestones mandatory in that case. > > > AFAIK, GH Milestones are useful when you want to assign an issue that > is > > not > > > yet fixed > > > see for example https://github.com/apache/maven-mvnd/milestones > > > > > > But it does not seem absolutely necessary, since GH Release Notes will > > get the > > > release content once the issue is fixed > > > example: https://github.com/apache/maven-mvnd/releases > > > > > > We'll need to define which GH Labels are available, and how the release > > notes > > > drafter use it to have better release notes > > > https://github.com/apache/maven-mvnd/labels > > > > > >> It is far less work than maintaining an issue. > > >> > > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy < > > ol...@apache.org>: > > >>> Hi, > > >>> This has been already discussed in the past. > > >>> But due to recent changes in ASF Jira infrastructure (limitation of > > >>> Jira users, validation of account creation). > > >>> Maybe we could reconsider moving from Jira to GH issues and why not > > >>> simplify the workflow as well. > > >>> I imagine not having to create an issue if a PR exists first (sounds > > >>> like duplicate work). > > >>> By the way, release notes will be automatically created from PRs. > > >>> (could be manually modified if a change doesn't have a PR). > > >>> > > >>> Regarding migration, we can start project by project. > > >>> Few options: > > >>> - extreme simplicity, do not migrate any data (just mark the Jira > > >>> project as read only with a banner/link to corresponding gh issues). > > >>> If someone really needs an issue to get fixed he will clone it to GH > > >>> - middle complexity, migrate only open issues (components moved as a > > >>> label) > > >>> - extreme complexity, migrate all issues of a project (components > > >>> moved as a label and version created) > > >>> > > >>> We can start by small projects such as cache-extension and one plugin > > >>> (compiler?) > > >>> > > >>> Regarding GH discussions, maybe we can open discussions for > > >>> https://github.com/apache/maven which sounds like a natural place > for > > >>> users to go. (discussions could be mirrored to a ML) > > >>> I do not have a strong opinion here, but I feel like opening > > >>> discussions for every single repo will be complicated to follow up. > > >>> > > >>> WDYT? > > >>> > > >>> cheers > > >>> Olivier > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >>> For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
