Just wanted to add my 2 cents into discussion. The beauty of open source that anyone who has enough resources can create a fork and maintain it, and send patches to upstream, eventually the repository which has more contributors will become upstream itself. Those who want to prove that github will help project can create a fork there, and synchronize changes with upstream. If you succeed and you would have more contributors than original project, the fork will become new upstream, everyone will benefit from that, If not than it will prove that github doesn't provide any benefits.
Cheers. On Fri, May 22, 2020 at 5:38 PM Brian Exelbierd <[email protected]> wrote: > > > > On Fri, May 22, 2020, at 11:17 AM, Ondřej Synáček wrote: > > But still, “meteorite” users would probably have to sign up for > > account to post a Gitlab issue. If we’re debating this one, it’s the > > friction of signing up for mailing list vs. signing up for Gitlab > > account. > > I think signing up for mailing list is easier and less frictionless. > > From my perspective it is actually the friction of a Issue Tracker/PR-based > workflow versus an email/patch-mail workflow. Depending on your background > and what you do today, one is more natural than the other. > > Through my own lens and based on my observations (necessarily biased I am > sure), the presence of an Issue tracker is becoming expected and a PR-based > workflow is the default. Many people are unfamiliar with patch-mail > workflows, especially those joining open source in newer projects. > > Not having PRs is, from my perspective, sad and painful, but maybe OK if we > have good onboarding documentation. > > Not having an issue tracker feels like we are losing stuff and working > harder, given that this is a low-frequency of participation (by hours/week) > project. > > A hybrid approach is what I would encourage: > > * An issue tracker that emails the list on new issues > * A suggestion that issues on list be opened in the issue tracker > * A requirement that all patches also have a tracking issue so they don't get > lost > * and, ideally a mirror repo where PRs can be submitted, even if the source > of "truth" remains the same. > > YMMV. > > regards, > > bex
