On the lack of Issues tab, though it doesnt seem to have been too much of an issue so far, we could certainly improve that by ensuring each repo README always covers how to raise things (or just links to the website page that covers it; I think some repos already do). Plus, opening Discussions again might be a suitable alternative for many of the things that get raised as issues but are actually just questions.
On Fri, 5 Apr 2024 at 17:15, Domenico Francesco Bruscino <bruscin...@gmail.com> wrote: > > I don't have a strong opinion on migrating from Jira to GitHub Issues. > I would prefer GitHub Issues only for its better integration and because > new users that reach from the GitHub repository could be confused to not > find the `Issues` tabs (most of the GitHub projects use it). > > Also GitHub Issues has a good REST interface, I'm using it in > GithubIssueManager[1]. > > @Justin Bertram <jbert...@apache.org> thanks the detailed doc!!! > > [1] > https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java > > On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > I would prefer to keep JIRA for their REST interface. > > > > Also: one thing to notice is the possibility of using private comments > > in JIRA. Say you ever have a security issue. I think you can have PMC > > private comments on JIRAs. I'm not sure you have the same in github > > issues. > > > > > > I didn't see a note about private comments on Justin's detailed doc > > (nice Doc BTW), but the private comments may be handy on handling > > sensitive issues. > > > > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <robbie.gemm...@gmail.com> > > wrote: > > > > > > The 'track version as Project' thing is interesting, though kinda > > > further underscores the limitations of Milestones which are really the > > > main surfaced way of handling versions. > > > > > > I'll bet some folks on the 'users' side of things looking at released > > > issues later would even miss that you are doing that (I would), since > > > Projects are kinda separate and get even further hidden away upon > > > completion; closed Projects are hidden/collapsed in the Issue/PR view > > > on expectations they are no longer 'interesting', requiring you to > > > spot that and expand the closed-projects view on each Issue/PR to see > > > the Project later. Which to be fair I think is actually decent > > > behaviour in general for their main use cases, since they aren't > > > really aimed to be used as versions but more for using the 'swimlane' > > > etc views given for managing/planning overall outstanding tasks to a > > > point of completion and will then most typically be > > > forgotten/less-interesting detail. > > > > > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon > > > <christopher.l.shan...@gmail.com> wrote: > > > > > > > > I am also on the Accumulo PMC and on that project we use Github issues > > > > and no longer use Jira. This switch was made before my time so I'm not > > > > sure of the reasoning. Personally, I don't really care too much either > > > > way as I've used both but I will just point out 2 things from my > > > > experience with it. > > > > > > > > 1) For version tracking, we use projects and not milestones. I don't > > > > know if this is the best way to do things but that's what we have been > > > > using and seems to work ok as you can list multiple projects > > > > (versions) for an Issue or PR: > > > > https://github.com/apache/accumulo/projects?type=classic > > > > > > > > 2) Robbie's point about whether or not Issues get opened is a really > > > > good point and something that is not consistent at all in Accumulo. > > > > What I have found is it is all over the place. In some cases people > > > > just open PRs and essentially are self documenting issues with the > > > > fix. In other cases people open up issues and then open up PRs. It > > > > does get confusing sometimes since they share the same numbering and > > > > name space. It may make sense to try and establish some guidelines if > > > > we go with Github Issues just so we are consistent about it. > > > > > > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <mattr...@gmail.com> > > wrote: > > > > > > > > > > > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell < > > robbie.gemm...@gmail.com> wrote: > > > > > > > > > > > > To the later point around Discussions, I do think enabling those > > could > > > > > > be good either way since, just like with Jira, people will often > > > > > > create Issues to ask questions rather than e.g mail a mailing list. > > > > > > They might use a Discussion instead though. > > > > > > > > > > +1 agree that having discussions enabled would be an upgrade for > > users, big improvement over mailing lists. > > > > > > > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbert...@apache.org> > > wrote: > > > > > >> > > > > > >> There's been a few threads about this general subject, but most > > have > > > > > >> concentrated on Classic in particular. I think it's worth > > discussing > > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into the > > details > > > > > >> of why a migration makes (or doesn't make) sense and what the > > challenges > > > > > >> may be. > > > > > >> > > > > > >> To this end I've put together this document [1]. I hope it will > > be of > > > > > >> service to the community as we consider this option. > > > > > >> > > > > > >> > > > > > >> Justin > > > > > >> > > > > > >> [1] > > > > > >> > > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review > > > > > > > > > > > > > -- > > Clebert Suconic > >
