Re: GH issues and GH discussions
On Sun, 28 May 2023 at 04:53, Michael Osipov wrote: > > Am 2023-05-27 um 12:10 schrieb Tamás Cservenák: > > 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. > > I truly do like your idea and also agree with Lukasz -- never give up to > control to a single party, especially one like MS. > > Upshot: One entry point with an empty repo. Well in case you didn't know the reason for "locking" Jira user creation (apart from avoiding spam) is the coming move (not sure if it's not already done) of Jira to Atlassian cloud (which have users number limitation that's why there is some cleaning of Jira's user). This limitation doesn;'t exist using gh. So this problem of single party is just going away, Jira has some features such as agile management, time estimation, sprint planning etc.. But are we really using that? Do we really need that? As far as I can see the usages are: 1. users or dev report a bug or a feature they would like to see 2. dev create a jira after having created a PR (because we said so) Then what do we do with that: 1. dev makes a comment and eventually assigns a fixed version. (which GH just set a milestone) 2. I propose here to not have to create a Jira if a PR exists because it is just duplicate paperwork. just create the PR assign a millestone, everything is in the same place no need to create another ticket somewhere else with the exact same description as the PR Github contributors are just used to that, it's simple and quick no need to add the burden of creating another entry in the tool which is not linked to the code you are happy to contribute to. We should be happy to have people contributing to code directly. And frankly once there is a PR created all the comments are made in the PR the jira is not commented anymore at all Using discussions sounds the same as stackoverflow or anything else, just another channel of communication. People have preferences and by the way this is the "mode" effect as well... (same as https://gitter.im/ was trendy etc..) It's just a matter of opening another channel, nothing else. Now we just need to be sure we listen to it and answer it I was thinking of opening discussions here https://github.com/apache/maven as it sounds like a more natural naming convention Maven is at Apache so that sounds like an easy typing url. Users will figure out and probably ask questions as they can do using u...@maven.apache.org and ask questions on core and plugins. but if you prefer something else why not. I'm just curious to see if this will really attract people. For sake of clarity, sending to ML does not need subscription, it's possible to send an email without being subscribed, the post will only need to be moderated and people can read answers in archives. > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: GH issues and GH discussions
You are correct, never used Polarion. Sounds like that might have been as bad as PVCS compared to nearly all other SCM IMO simple is better when it comes to that stuff and linking tickets isn't that hard. I've not done anything with gitlab but on GH its trivial, maybe not the best but just dropping comments with URL links hooks things together. Maybe not elegant. But then again I don't have 100s of possible variations of setup. Only improvement in Jira I like is service desk and using it for Kanban. Even then too many clicks to just add a note that I’m doing something, here are details, close it. My day job ruined its general usage though. Has more to do with the customization they added to such an extent that it’s a time tracker and developers now spend more time there then actually coding so management and product teams are happy and they continue to assume coding takes no time. -Original Message- From: Michael Osipov Sent: Saturday, May 27, 2023 4:31 PM To: dev@maven.apache.org Subject: Re: GH issues and GH discussions Am 2023-05-27 um 22:21 schrieb Jeremy Landis: > Not sure if was mentioned. Spring moved all their legacy Jira for all their > projects entirely to GitHub Issues. Believe it was done with everything. > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsprin > g.io%2Fblog%2F2019%2F01%2F15%2Fspring-framework-s-migration-from-jira- > to-github-issues=05%7C01%7C%7Cd2dc9ef5900c4dfc10e508db5ef14e59%7C > 84df9e7fe9f640afb435%7C1%7C0%7C638208162715371992%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI6Mn0%3D%7C3000%7C%7C%7C=Z5DiJtHc5rqBVITjWitrTQ%2FtkhRFCKD%2 > BJ%2F%2FAw6we%2B9Q%3D=0 > > Now concerns of MS are unfounded thus far. MS is biggest user of github > which is why they bought it. Not sure that is still the case but after some > 14 years, issues have not cost anything and moving them back out is about as > easy of a process. Plus issues and pull requests are effectively the same > thing (at least numbering wise). Comparing to items I've seen mentioned here > like google code shutting I don’t think are very fair comparisons. I would > lean to look at spring and see their motivation. > > Rest is my 2 cents don't feel inclined to read my rambling. > > From a plugin owner where all I use issues only, working at a job where Jira > has become a time tracking tool, and the fact its so hard to work with any > github team that uses jira Sure I figured it out with maven but it’s a > serious painand leads to...how I feel. And I’m sure true for most others > are the same. I prefer to not even contribute or be active as a result on > any repos that are using jira. Let's be honest here. Atlassian is just > doing nothing with their products. Jira looks the same today it did 14 years > ago. Bitbucket looks the same as Stash before it with some minor color > changes. They are losing market share as a result as they cannot even handle > volume. Jira is a bloated mess. If team is trying to do agile, that’s built > into github too. Its so much easier to be in one single place. I've heard > these arguments that github might go away for years now or MS owning it now > might do like Oracle. They did something right here. MS consideration is a > lot like Oracle, super heavy handed in what they do but the foundation was > set and unlike MS trying to end Slack with ugly Teams, they choose not to do > the same with GH. Outside of some assumed "they mess it all up and ruin our > lives", I think the benefits far outweight all concerns. > > I'd be -1 on only having issues in one place but maybe as a jumping off point > to find all the repos. Blame feature doesn't really help, no one sees those. > Issues needs turned on for all repos. In fact, if you want to continue > jira, fine, but open issues up. If someone as a small concern, only making > them raise on mailing lists or jira is a nightmare. This is by far biggest > reason I hate bitbucket - no issues, use jira. Too many times and I'm sure > I’m not alone, its easier to just ignore the issues outright and try to find > alternatives due to complexity. This was true of the old hosting sites too, > old days were very hard to be casual contributor. The easier it is, the more > likely more contributors are engaged. Interesting, having used JIRA for 10+ years as well as GH and a huge GL installation (300 000+ users), I consider that both GH's and GL's issue handing is just inferior to JIRA. Especially when it comes to linking and alike. Note: I am looking only from a technical perspective, leaving politics and capitalism aside. Regarding UI: Though, I don't understand your problem with JIRA UI -- you haven't used Polarion. That has a horrible UI and UX, JIRA is decades ahead. Plus, changing somehing for the sake of the change is just wrong. If something works well, just a bit
Re: GH issues and GH discussions
Am 2023-05-27 um 22:21 schrieb Jeremy Landis: Not sure if was mentioned. Spring moved all their legacy Jira for all their projects entirely to GitHub Issues. Believe it was done with everything. https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues Now concerns of MS are unfounded thus far. MS is biggest user of github which is why they bought it. Not sure that is still the case but after some 14 years, issues have not cost anything and moving them back out is about as easy of a process. Plus issues and pull requests are effectively the same thing (at least numbering wise). Comparing to items I've seen mentioned here like google code shutting I don’t think are very fair comparisons. I would lean to look at spring and see their motivation. Rest is my 2 cents don't feel inclined to read my rambling. From a plugin owner where all I use issues only, working at a job where Jira has become a time tracking tool, and the fact its so hard to work with any github team that uses jira Sure I figured it out with maven but it’s a serious painand leads to...how I feel. And I’m sure true for most others are the same. I prefer to not even contribute or be active as a result on any repos that are using jira. Let's be honest here. Atlassian is just doing nothing with their products. Jira looks the same today it did 14 years ago. Bitbucket looks the same as Stash before it with some minor color changes. They are losing market share as a result as they cannot even handle volume. Jira is a bloated mess. If team is trying to do agile, that’s built into github too. Its so much easier to be in one single place. I've heard these arguments that github might go away for years now or MS owning it now might do like Oracle. They did something right here. MS consideration is a lot like Oracle, super heavy handed in what they do but the foundation was set and unlike MS trying to end Slack with ugly Teams, they choose not to do the same with GH. Outside of some assumed "they mess it all up and ruin our lives", I think the benefits far outweight all concerns. I'd be -1 on only having issues in one place but maybe as a jumping off point to find all the repos. Blame feature doesn't really help, no one sees those. Issues needs turned on for all repos. In fact, if you want to continue jira, fine, but open issues up. If someone as a small concern, only making them raise on mailing lists or jira is a nightmare. This is by far biggest reason I hate bitbucket - no issues, use jira. Too many times and I'm sure I’m not alone, its easier to just ignore the issues outright and try to find alternatives due to complexity. This was true of the old hosting sites too, old days were very hard to be casual contributor. The easier it is, the more likely more contributors are engaged. Interesting, having used JIRA for 10+ years as well as GH and a huge GL installation (300 000+ users), I consider that both GH's and GL's issue handing is just inferior to JIRA. Especially when it comes to linking and alike. Note: I am looking only from a technical perspective, leaving politics and capitalism aside. Regarding UI: Though, I don't understand your problem with JIRA UI -- you haven't used Polarion. That has a horrible UI and UX, JIRA is decades ahead. Plus, changing somehing for the sake of the change is just wrong. If something works well, just a bit finetuning. Don't reinvent the wheel. M
RE: GH issues and GH discussions
Not sure if was mentioned. Spring moved all their legacy Jira for all their projects entirely to GitHub Issues. Believe it was done with everything. https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues Now concerns of MS are unfounded thus far. MS is biggest user of github which is why they bought it. Not sure that is still the case but after some 14 years, issues have not cost anything and moving them back out is about as easy of a process. Plus issues and pull requests are effectively the same thing (at least numbering wise). Comparing to items I've seen mentioned here like google code shutting I don’t think are very fair comparisons. I would lean to look at spring and see their motivation. Rest is my 2 cents don't feel inclined to read my rambling. From a plugin owner where all I use issues only, working at a job where Jira has become a time tracking tool, and the fact its so hard to work with any github team that uses jira Sure I figured it out with maven but it’s a serious painand leads to...how I feel. And I’m sure true for most others are the same. I prefer to not even contribute or be active as a result on any repos that are using jira. Let's be honest here. Atlassian is just doing nothing with their products. Jira looks the same today it did 14 years ago. Bitbucket looks the same as Stash before it with some minor color changes. They are losing market share as a result as they cannot even handle volume. Jira is a bloated mess. If team is trying to do agile, that’s built into github too. Its so much easier to be in one single place. I've heard these arguments that github might go away for years now or MS owning it now might do like Oracle. They did something right here. MS consideration is a lot like Oracle, super heavy handed in what they do but the foundation was set and unlike MS trying to end Slack with ugly Teams, they choose not to do the same with GH. Outside of some assumed "they mess it all up and ruin our lives", I think the benefits far outweight all concerns. I'd be -1 on only having issues in one place but maybe as a jumping off point to find all the repos. Blame feature doesn't really help, no one sees those. Issues needs turned on for all repos. In fact, if you want to continue jira, fine, but open issues up. If someone as a small concern, only making them raise on mailing lists or jira is a nightmare. This is by far biggest reason I hate bitbucket - no issues, use jira. Too many times and I'm sure I’m not alone, its easier to just ignore the issues outright and try to find alternatives due to complexity. This was true of the old hosting sites too, old days were very hard to be casual contributor. The easier it is, the more likely more contributors are engaged. -Original Message- From: Michael Osipov Sent: Saturday, May 27, 2023 2:53 PM To: dev@maven.apache.org Subject: Re: GH issues and GH discussions Am 2023-05-27 um 12:10 schrieb Tamás Cservenák: > 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. I truly do like your idea and also agree with Lukasz -- never give up to control to a single party, especially one like MS. Upshot: One entry point with an empty repo. B CB [ X ܚX KK[XZ[ ] ][ X ܚX PX] [ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ X] [ \X K ܙ B
Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4
Am 2023-05-26 um 21:29 schrieb Michael Osipov: Hi, we solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353222 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MPIR/issues Staging repo: https://repository.apache.org/content/repositories/maven-1948/ https://repository.apache.org/content/repositories/maven-1948/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-reports-plugin-3.4.4-source-release.zip Source release checksum(s): maven-project-info-reports-plugin-3.4.4-source-release.zip sha512: c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b Staging site: https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: GH issues and GH discussions
Am 2023-05-27 um 12:10 schrieb Tamás Cservenák: 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. I truly do like your idea and also agree with Lukasz -- never give up to control to a single party, especially one like MS. Upshot: One entry point with an empty repo.
Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4
+1 pt., 26 maj 2023, 21:29 użytkownik Michael Osipov napisał: > Hi, > > we solved 6 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353222 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MPIR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1948/ > > https://repository.apache.org/content/repositories/maven-1948/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-reports-plugin-3.4.4-source-release.zip > > Source release checksum(s): > maven-project-info-reports-plugin-3.4.4-source-release.zip > sha512: > > c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b > > Staging site: > > https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4
+1 Thanks! El vie, 26 may 2023 a la(s) 16:29, Michael Osipov (micha...@apache.org) escribió: > Hi, > > we solved 6 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353222 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MPIR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1948/ > > https://repository.apache.org/content/repositories/maven-1948/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-reports-plugin-3.4.4-source-release.zip > > Source release checksum(s): > maven-project-info-reports-plugin-3.4.4-source-release.zip > sha512: > > c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b > > Staging site: > > https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: GH issues and GH discussions
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 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 于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 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 于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 于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
Re: GH issues and GH discussions
> 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 于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 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 于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 于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] > > >> > > >
Re: GH issues and GH discussions
So much spam got into jira, it had to be locked down. You should see the junk I mod out of the Xalan lists... Gary On Sat, May 27, 2023, 06:55 Elliotte Rusty Harold wrote: > On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák > wrote: > > > 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), > > > > > Good points all around. > > 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? > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: GH issues and GH discussions
How does StackOverflow fit in if at all? Any pros and cons to share? Gary On Sat, May 27, 2023, 06:43 tison 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 于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 于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 于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
Re: GH issues and GH discussions
On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák wrote: > 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), > Good points all around. 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? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: GH issues and GH discussions
> 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 于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 于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 于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
Re: GH issues and GH discussions
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 于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 于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 >>
Re: GH issues and GH discussions
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 于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 > 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 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
Re: GH issues and GH discussions
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 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 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 > >>> > >>> - > >>>
Re: GH issues and GH discussions
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 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 : 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
Re: GH issues and GH discussions
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 : > > 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
Re: GH issues and GH discussions
on testing GH issues migration from Jira: yes cache-extension [1] looks like an interesting example, given it has a small history with its Jira content we also have mvnd which uses GH issues from the start: testing and making clear practices on release and release notes could also be worked there [2] we'll need to write down what practical steps such a migration requires => probably a good fit for our Wiki, where we already organized equivalent updates in the past [3] on using GH discussions, I suppose this should be an independent next discussion [1] https://github.com/apache/maven-build-cache-extension [2] https://github.com/apache/maven-mvnd [3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit : > 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
