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 > >
