> It occurs to me that not that long ago, Jira used to be open signup. > is there a specific reason it changed? Does that reason still apply?
It's still open and self-serving at [1]. Just need one more moderate step from committers or PMC members. To reduce spam, yes. Best, tison. [1] https://selfserve.apache.org/jira-account.html Gary Gregory <garydgreg...@gmail.com> 于2023年5月27日周六 18:55写道： > How does StackOverflow fit in if at all? Any pros and cons to share? > > Gary > > On Sat, May 27, 2023, 06:43 tison <wander4...@gmail.com> wrote: > > > > single point of entrance > > > > One last comment - it's a maintainer strategy to reduce the burden of > > monitoring multiple channels, and users generally gather to where their > > questions can be answered. But it's not a user strategy; they ask on the > > platform they are used to or closest to where the issue happens. > > > > So we may not say "a specific channel is _not_ supported, you should not > > ask there", but "most of the critical mass answering questions on > platform > > X". Users make their choice reflected to where the critical mass work > > instead of being forced there. > > > > Best, > > tison. > > > > > > tison <wander4...@gmail.com> 于2023年5月27日周六 18:36写道： > > > > > 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 > > >>> > > > >>> > > > >>> > > >> > > >
