curious: why use own hosting rather than github?
Remus Buzatu
r.buzatu90 at gmail.com
Fri May 22 18:18:02 CEST 2020
Perfectly said !
> On 22 May 2020, at 20:11, yanchenko.igor at gmail.com wrote:
>
> 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 <bex at pobox.com> 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
More information about the Password-Store
mailing list