It is unclear why the infrastructure team cannot allow a variety of
authentication mechanisms - Gitee for example enables SMS authentication
and validation by any validated Gitee user to obtain basic
functionality. My expectation is that any committer or validated
contributor (not just PMC) can validate potential Jira users. This
would lessen the burden on PMC members.
Making it easy to report is great, in addition to user and developer
mailing lists, GitHub issues has been enabled for this purpose. A
little friction may also mean more thought out issues that should and
will be worked on.
Some people may find GitHub inconvenient[1,2,3]. With GitHub one cannot
easily modify either the forge or the issue tracking system. Maybe other
issue tracking systems should be considered especially if better
validation mechanisms cannot be used with Jira, for example Redmine,
Bugzilla - this does place more burden on Apache Software Foundation,
but if project contributors also want to improve issue tracking, this
gives an opportunity to do so.
Finally, can the data on GitHub issues be mirrored somewhere else? If
so where and with what metadata?
Benson
1) https://man.sr.ht/~etalab/logiciels-libres/why-sourcehut.md
2) https://www.gnu.org/software/repo-criteria-evaluation.html
3) https://postmarketos.org/blog/2022/07/25/considering-sourcehut/
On 10/23/22 15:01, Andrew Lamb wrote:
It is my opinion that github issues have served us very well in the Arrow
Rust implementation. I haven't heard anyone complain about github or
suggest we should look for alternatives.
One of the major benefits is that everyone who contributes to the project
already has to have a github account, so using github issues needs no other
setup and the UI is very familiar (e.g. markdown syntax, etc).
We also use github issues in my job and it works well in that context as
well.
After using Jira (as I had for 10+ years), it certainly takes time getting
used to a new interface but I found it is "good enough" for all project
planning and coordination needs I have had.
In terms of migration, when we switched from JIRA to github issues I wrote
a simple python script that copied content from JIRA to github and left
bidirectional pointers -- it wasn't perfect but seems to have gotten the
job done
Andrew
On Sat, Oct 22, 2022 at 2:47 PM Todd Farmer <t...@voltrondata.com.invalid>
wrote:
I can't claim experience migrating to GitHub issues, but I've done some
work with Jira APIs and import/export tools. I'm happy to help draft a
proposal or proof-of-concept to validate if nobody else expresses interest,
or to assist anybody who does.
Todd
On Sat, Oct 22, 2022 at 12:08 PM Neal Richardson <
neal.p.richard...@gmail.com> wrote:
I would guess that mostly could be handled with labels, though that does
turn into lots of labels. GitHub also seems to have grown some useful
features for this, like Projects [1] and Milestones, and we should look
into how to make them work for us.
While I agree that those features in the current Jira instance are nice
and
we should seek to preserve them, I fear that if we chose to adopt a
different issue tracker other than GitHub, we wouldn't solve the
barrier-to-entry problem--we'd only be moving it.
Regarding migration, I'm sure there are export and import APIs, the
question is how much effort/code we'd have to put in to make it happen.
Does anyone here have experience doing this?
Neal
[1]:
https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects
On Sat, Oct 22, 2022 at 10:19 AM Antoine Pitrou <anto...@python.org>
wrote:
Hi Neal,
Le 22/10/2022 à 15:35, Neal Richardson a écrit :
Their email says:
Infra knows this process change places an increasing burden on PMC
members
for managing contributors, and makes it harder for people to
contribute
bug reports.
We suggest projects consider using GitHub Issues for customer-facing
questions/bug
reports/etc., while maintaining development issues on Jira.
but I think that having a two-tiered system for issue tracking
presents
some notable downsides for us, including:
* Increased barriers to entry for new contributors and a sense of
inequality between "us" and "them". There's already too much friction
IMO,
and this pushes that up significantly.
* Maintenance burden of triaging and synchronizing issues across
trackers
sounds like a lot for us to take on. I'd prefer the active
maintainers
on
the project spend their time shipping useful, reliable software, not
doing
bookkeeping.
I fully agree with your concerns. So I'm +1 on migrating to *something
else*.
The one thing I would not want to lose, though, is the categorization
facilities we currently have in Jira. Namely: Component, Affects
version, Fix version, Type (bug/improvement/task...), Issue links
(superceded by/relates to/is caused by...), Priority (at least
Minor/Major/Blocker).
How much of that can be recreated in Github Issues, or any other
alternative?
A secondary question is whether it's possible to migrate the current
issues. Would be nice to have, but not blocking either (IMHO).
Regards
Antoine.
