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