I am +1 to move to GH issues. In Apache BookKeeper and Pulsar we had a script that did the migration pretty seamlessly and I used that script also for other OSS projects outside of the ASF. (I can't find it now, but it should be buried in some git repo somewhere)
Enrico Il Sab 27 Mag 2023, 13:02 tison <wander4...@gmail.com> ha scritto: > > 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 > > > >>> > > > > >>> > > > > >>> > > > >> > > > > > >
