I've seen multiple Apache projects using GitHub for issue tracking, but are not really positive examples. Often they don't use the milestones and labels available, I'd be sad if we'd end up with that style.
GitHub on it's own is usually good enough if used correctly, when it's helped with bots. There are multiple OSS projects doing decent work and administration using GitHub only. All the (multiple) mailing lists, stack overflow and JIRA are definitely barriers for new contributors. They require familiarity (people born after 2000 are not familiar with mailing lists or JIRA, but they are with GitHub) and setup (filters, notifications). I admit this helps reducing the noise, dealing with serious participants only, making things the "right way", but I wanted to note this different aspect too. Keeping everything (discussions, issues, PRs) in one place has huge added value, but not for the core members and people working in this environment for years. While I don't necessarily think it is worth switching now, converging to a single platform improves the reach and diversifies/grows the Arrow community in the long run. I understand if we stick with JIRA, but I'm 100% sure there are people not asking questions, not raising issues, not giving feedback and not contributing because of the mailing lists and JIRA already. They wouldn't have the best ROI, but we can acknowledge there is a room for improvement. Best regards, Adam LIppai On Tue, Mar 2, 2021 at 10:26 AM Antoine Pitrou <anto...@python.org> wrote: > > Hi Jorge, > > On Tue, 2 Mar 2021 08:55:03 +0100 > Jorge Cardoso Leitão <jorgecarlei...@gmail.com> wrote: > > Hi, > > > > FWIW, the amount of bureaucracy that goes into JIRA is a major > contributing > > factor for the reduction of my time commitment to this project by 80%+. > > Can you expand a bit on this? In particular, which aspects of using > JIRA feel bureaucratic? Is it the requirement to create a new issue > for each PR? Or is it other concerns (such as the UI for entering or > searching issues)? > > I can't say I like JIRA myself, but at least it provides the > classification and navigation features that I would expect from an > issue tracker. The Github issue tracker AFAIK is rudimentary and not > really practical when a project has accumulated many issues (but they > may have changed this recently). > > > The major challenge is that most discussions happen where PRs are created > > and seen, which is on github, but JIRA and mailing list is used for other > > types of decisions. In this model, how do we preserve curated information > > about the decision process while at the same time leverage both JIRA and > > github's capabilities? > > In my experience, discussion on JIRA is about the issue itself (for > example diagnosing a bug or discussing a feature), then discussion on > the PR is about the implementation. JIRA discussions are generally > readable by users (and indeed, users often participate) while PR > discussions are really for developers of the project. > > > OTOH, asking contributors to create a jira account > > and committers to add the person as contributor, as well as the email > spam > > and the merge process is a large barrier. > > FWIW, I've set up a mail filter that sends all "work logged" automated > mail to the trashbin. I agree it's unfortunate that developers have to > do that. I also have other qualms with the Apache JIRA configuration, > such as the fact that "labels" (keywords) are shared between all > projects, so there is essentially a million of them with no effort at > taxonomy. > > > IMO the foundation could be clearer wrt to what does it mean with > > information being preserved and available (e.g. on apache servers?) and > if > > yes, follow it through by hosting all their projects on their own github > / > > gitlab / whatever, where issues and PRs are on the same platform, and > offer > > SSO for contributors as a way to prove identity across the system. But > that > > is also a complex operation with a lot of unknowns... > > From what I see of the ASF's velocity, I wouldn't expect such a large > breakthrough in the short future. > > (this is not trying to badmouth the ASF, just a pragmatic evaluation) > > Regards > > Antoine. > > >
