I agree with Tamas' suggestion about the single point of entrance. Here are several examples I experienced:
1. Apache SkyWalking[1] uses a single GH Issue to track all its issues and Discussions for user questions and some rough ideas. 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH Issues for different repos, while for the tightly coupled site repo[3], I merge the Issue tracker to the main repo. Single Discussions instance for all "Pulsar" related questions. 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project for all its repos issue trackers, and only user@ and user-zh@ mailing lists for user questions. Given their high responsiveness, it works well for most of its users. Although other unofficial channels (with PMC members there) (like DingTalk group or Slack workspace) exist to answer questions, most users can be guided to the mailing list since it's still the most active channel. Maven has a more complex repo cluster[4], and decisions can differ. Best, tison. [1] https://github.com/apache/skywalking [2] http://github.com/apache/pulsar [3] http://github.com/apache/pulsar-site [4] https://maven.apache.org/scm.html tison <wander4...@gmail.com> 于2023年5月27日周六 18:28写道： > 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 >> > >> > >> >
