The top reason for me to support moving our project to GitHub is to lower
friction for the growth of the Lucene developer community.
I myself am far less comfortable with GitHub issues than Jira, but that's
really unimportant. I can and will figure it out (like highlighting text
and hitting "r", yay!). I would hope/expect the same for all "old-timers"
here :)
Our community grows only at its periphery, with younger, passionate
people (who generally have strong comfort in GitHub and not with Jira).
Anything and everything we can do to reduce the friction for such Fresh
Eyes / Shoshin / 初心 users, we must do. The long-term survival of our
(currently still vibrant, but that can change) community relies on
continued growth by doing everything possible to encourage new users,
growing to contributors, to committers, to PMC members, to Apache members.
I put this in the same bucket as "try to promptly respond to new people who
send emails to our lists" and "aggressively try to fix the silly issues a
new contributor hits" (like the recent "gradlew tidy" improvements from
Rich Bowen's "the the" first Lucene contribution).
Fresh Eyes is a sharp tool that quickly dulls, and we old-timers can no
longer sense nor appreciate/empathize-with the problems new contributors
hit, to our ("whole Lucene dev community") detriment.
Also, I really do not like that Jira silently blocks your IP if you try to
add a link to an external PDF that has the word "dissertation" in it! This
leads to confusion (especially if you are coming through a VPN since that
VPN's endpoint is blocked so anyone else sharing that endpoint, later, will
also see the silently dropped packets (spinning browser) when trying to add
comments to Jira). This is just a pet peeve LOL. Also, Apache's slow
adoption/enabling of modern Jira features like supporting Markdown does not
help the Jira case, also a pet peeve!
But big +1 on ensuring we can always recover all of our (future) GitHub
issues + metadata in the future event where we suddenly decide to move to
something else. This should not be a one-way door, and as part of the VOTE
process, we should do our best to confirm this.
I also feel it is vital we are able to migrate our full Jira issue history
to GitHub issues. Dawid's (herculean) efforts to preserve our full
Subversion history on moving to git was incredible and really vital. To
this day, you can "git log" and at the very bottom you see the first few
Lucene commits (under Apache Jakarta from 2001, on migrating from
SourceForge)! Lucene is a unique open-source project, with SO much
history, still so vibrant after so much time, surviving crazy JVM/JDK bugs,
and its widespread and growing adoption now. We must preserve that
history: it is a vital part of Lucene's current appeal and growth. Those
who do not study history are doomed to repeat it! We should not
intentionally throw our history away. So I will (most likely) VOTE -1 if
we cannot preserve our detailed Jira issue history on migration, and
likewise if we cannot do so (based on our best prediction) in the future on
migration from GitHub issues to elsewhere.
Mike McCandless
http://blog.mikemccandless.com
On Wed, May 11, 2022 at 12:58 AM Tomoko Uchida <tomoko.uchida.1...@gmail.com>
wrote:
> Thanks everyone for your thoughtful comments - I think we can learn a lot
> from Solr Operator project.
>
> And then, I'd appreciate the feedback from Julie; not only because of the
> support for the migration but also because we surely need feedback from
> committers/contributors who actively create or review patches/PRs on a
> regular basis and drives this project like you.
> Of course, advisory comments from the whole community are really helpful
> and I welcome feedback from all developers, regardless of the activities on
> Lucene.
>
> I don't think I'm good at facilitation, I'll try to be here though :)
> I hope we'll continue a good conversation, and then, we can be confident
> opening the official vote.
>
> Tomoko
>
>
> 2022年5月11日(水) 9:36 Julie Tibshirani <juliet...@gmail.com>:
>
>> I don't have much to add to the (already very detailed!) discussion, just
>> wanted to add my support for the idea of moving to GitHub. I've had a good
>> experience with GitHub issues for other repos I contribute to and find the
>> mark-up language comfortable and expressive. I also think switching to
>> GitHub could help newer contributors engage with the project. When I first
>> started contributing I found it really hard to navigate and search JIRA for
>> issues I was interested in. Now I rely on Mike's wonderful JIRA search tool
>> (https://jirasearch.mikemccandless.com/search.py), but most new
>> contributors do not know about it (and it adds another dependency on top of
>> GitHub and JIRA).
>>
>> Julie
>>
>> On Tue, May 10, 2022 at 12:41 PM Houston Putman <hous...@apache.org>
>> wrote:
>>
>>> I'm not going to get into how the Github automation should be done,
>>> that's a whole separate thread. But I agree too much automation can
>>> certainly be annoying and a burden. You can see this a lot in the
>>> kubernetes repos (https://github.com/kubernetes), though it does come
>>> with its reasons.
>>>
>>> Kubernetes is a good example of a project MUCH bigger than Solr
>>> successfully using Github Issues & PRs. So I don't really think it's a
>>> question if Github is feature-rich enough to handle our use case, it's
>>> pretty clear that it is. It will certainly be a change in process, but I
>>> think that all of these very successful open source projects show that it's
>>> a valid option for our projects. I think the ultimate questions are:
>>>
>>> - Which will be easier for users to find relevant information?
>>> - Which reduces the amount of bureaucracy needed to contribute to
>>> the project?
>>> - Which fits into the workflows of existing committers the best?
>>>
>>> To me Github comes up on top, even though there are things that JIRA
>>> does better.
>>>
>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't
>>> think helm is deprecated
>>>
>>> On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcusea...@gmail.com>
>>> wrote:
>>>
>>>> I recommend people take a look at the now deprecated helm project. It
>>>> was very difficult to land PRs because they had so much governance and
>>>> automation. For a data store as mature as SOLR, I would suggest it is
>>>> needed.
>>>>
>>>> Many issues are worth a read: https://github.com/helm/helm
>>>>
>>>> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.h...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <hous...@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>
>>>>>> Most modern open source projects use Github Issues for their issue
>>>>>> tracking, so it's definitely doable, and really what new
>>>>>> users/contributors will be expecting. Also I see that much discussion is
>>>>>> already done on PRs, and JIRAs are mainly there just for
>>>>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>>>>> in.
>>>>>>
>>>>>>
>>>>> On that note, many such projects I find it more difficult to get
>>>>> clarity on whether or not I'm affected by the issue, or in what version it
>>>>> was resolved. Usually i can be achieved by clicking on the referenced
>>>>> commit, and then inspecting what tags are on that commit, but it's several
>>>>> clicks and a minute or two vs just looking at the field in Jira...
>>>>>
>>>>> This can be made easier by using milestones as seen here (random
>>>>> example, used gradle because it's a very large, healthy project):
>>>>> https://github.com/gradle/gradle/issues/20182
>>>>>
>>>>> But I've seen a lot of projects that don't do that... which probably
>>>>> colors my view a bit.
>>>>>
>>>>> -Gus
>>>>>
>>>>> --
>>>>> http://www.needhamsoftware.com (work)
>>>>> http://www.the111shift.com (play)
>>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Eagan
>>>>
>>>>
