Thanks Gus, for providing the clear pros/cons list and posing an objection.
I welcome constructive criticism that strengthens our discussion.

Among the informative list, I'd highlight a new perspective I haven't seen
so far (and honestly, I haven't considered): Security issues that are
visible to PMC only.
GitHub-inclined people (including me) would need to answer or find
solutions for it if it's an inevitable feature for Lucene. As an obvious
answer, we'll be able to continue to use Jira for such sensitive issues;
but there could be more sophisticated/integrated ways for that?
I'm not knowledgeable about current access control for Jira issues. Does
anyone among the PMC members have an idea - or perhaps we could borrow a
solution from other large/popular projects operated on GitHub (yes,
Elasticsearch and OpenSearch are in my mind).

As for accepting contributions (patches) from developers who don't use
GitHub for some reason, I think we MUST support contribution paths that do
not rely on GitHub PR, and I suppose every committer agrees with me on that.

Tomoko


2022年5月7日(土) 6:46 Gus Heck <gus.h...@gmail.com>:

> I think both tools have their merits and drawbacks
>
> What I like about Jira:
>
>    - It has ample room and configuration for issue metadata and
>    customizable workflows and in general a deep feature set
>    - It has user roles, PMC members can see security issues that are
>    hidden from the world...
>    - I've used it for almost 20 years so It's familiar to me.
>    - It's hosted at the ASF by the ASF so nobody but the ASF can
>    determine access or hold it hostage (I think, correct me if I'm wrong
>    and we're now using atlassian cloud versions).
>
> What Ii do not like about Jira
>
>    - They have had LONG standing issues with text and visual mode not
>    round-tripping (switching between them alters the text and often destroys
>    formatting) which is something even cheap blogging software usually gets
>    right.... this is EXTREMELY FRUSTRATING at times where the proper name of
>    something in code includes an underscore. Especially bad is the fact that
>    the do provide a way to escape things like underscores but the transition
>    between visual and text destroys that escaping, making it useless, and if
>    you carefully set up the escapes in text mode, one small edit by someone
>    else (perhaps fixing a typo) in visual mode destroys all your hard work!
>    GRRRR... And of course text mode is sometimes hard to predict so working in
>    text mode with any non-trivial formatting that you may wind up re-editing
>    several times which at apache sends multiple emails to the list...
>    usability nightmare.
>    - They switched to a default search result layout that wasn't a
>    sortable table/list. This irritates me because I never want to randomly
>    fill 70% of the screen with the top hit on a search and have almost no info
>    about all the other results. Typically I want to immediately sort by issue
>    number to find recent issues (or older issues depending). Even if text
>    relevancy is the important thing in my search, assuming the top hit is what
>    I want is poor.
>    - By default searches typed in the easily accessed search box run
>    against every project so then the very first thing I have to do is re-run
>    with a project filter. Maintaining a project context would be very helpful.
>    - UI can become cumbersome for filtering on issue fields with many
>    values (typeahead search presumes you know the name to start with).
>    - Sometimes slow.
>
> What I like about Github
>
>    - It fixes the first and third issue I don't like about jira (edit
>    round trip and typically has a project context).
>    - UI updates without explicit refresh
>    - Generally nice look and feel
>    - Integration of github actions, pull requests, review, and code
>    repository is excellent.
>    - Closing issues via commit message is nice for small projects...
>
> What I don't like about github.
>
>    - Very limited and no custom issue metadata
>    - arbitrary file attachments are not supported. Notably .patch is not
>    included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, DOCX,
>    FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX,
>    TXT, XLS, XLSX or ZIP).
>    - Search interface for issues is the equivalent of the Jira JQL search
>    line, and requires learning their syntax for anything but the most basic,
>    and is:issue must be retained (and wastes space in the small text field) or
>    it suddenly starts finding non-issues items.
>    - No concept of workflow (without add/on or plugins).
>    - Closing issues via commit message is not good where you would want
>    to ensure review or have any sort of workflow
>    - It's owned by Microsoft, which while MUCH improved in recent years
>    has a horrible dark, evil past WRT open source and standards. Above
>    allegations regarding political banning of individuals is also very
>    troubling and unfortunately, increasingly relevant in the current global
>    political landscape.
>
> From the lucene perspective I see some things we have now in Jira that I
> don't see a way to maintain in github
>
>    - Security issues that are visible to PMC only (more common for solr,
>    but perhaps needed for lucene sometimes as well)
>    - Patch review based on an attached patch.
>    - Accepting patch files instead of pull requests...
>    - Contribution by folks who for some reason cannot use github (either
>    blocked by work or github politics or, unwilling to accept githubs
>    terms/privacy etc.)
>    - Document with each issue the Affected version and the fixed version.
>    - While one can create arbitrary labels, they are not segregated into
>    fields so we would have to put up with what is effectively a single field
>    for priority, component, and resolution
>    - No way to enforce that a resolution label is applied to the issue.
>
> I feel that Github issues are simply lacking in depth and riding along on
> the virtue of their integrations. I feel like their issue tracking
> implementation is a lower priority sideline to their code repository (so
> they can say they have it).  On the flip side Jira has become hugely
> entrenched in the industry and its profits are no-longer tied to innovation
> or even usability... and it shows. So I am basically dissatisfied with both
> (for most of the last 20 years I've been known to mutter about writing my
> own issue tracker... I've not met one that didn't irritate me somehow,
> though I haven't actually tried yet, because that's a LOT of work ;) ).
>
> Given how many things I've listed, it's likely something's wrong or
> misapprehended, so certainly speak up if I'm just unaware of something in
> github.
>
> In the end I don't feel like the benefits of github are worth giving up
> the data quality and features that we do actually use in Jira, so I'm -0.9
> on moving to github.
>
> -Gus
>
>
> On Fri, May 6, 2022 at 11:11 AM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <rcm...@gmail.com> wrote:
>>
>> As far as replies, in github I highlight the part of the thing i want
>>> to reply to, and press 'r' key on my keyboard. it quotes it and
>>> everything. Really convenient to me.
>>>
>>
>> Whoa, thank you!!  I had no idea GitHub has such extensive keyboard
>> shortcuts (just type ? to see them all).
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Reply via email to