On 16 December 2015 at 08:00, Barry Warsaw barry@python.org wrote:
On Dec 15, 2015, at 10:51 PM, Jesus Cea wrote:
I realize that my weight as a very low activity committer is minimal and I don't have an alternative proposal.
An alternative which meets many of your criteria is the GitLab proposal in PEP 507.
(TL;DR of below: my own main concern has shifted to ensuring that, even if we choose GitHub now, we can still add GitLab, Kallithea or Phrabricator in parallel later, without disrupting the folks that genuinely prefer GitHub based workflows)
For me personally, regardless of what happens in the near term, I still want to see us eventually offer a free-software-needs-free-tools friendly contribution path running on a project like GitLab CE, Kallithea or Phabricator.
However, I'm also satisfied that, regardless of what we do on the free software side of things, we want to offer a GitHub based contribution path for folks familiar with that workflow (I now see this as similar to the fact we actively work to support both Windows and Mac OS X as user and contributor platforms, even though they're proprietary operating systems).
Having accepted that my own long term goal is to minimise barriers to contribution both for folks accustomed to using popular proprietary platforms *and* for folks that aim to use exclusively free software, I've come around to the view that a compromise "open enough" solution that leaves *nobody* especially happy with the outcome likely isn't a good approach, and hence it's better to pursue a "parallel contribution path" model where we create two *interoperable* workflows, rather than a single *compromise* workflow.
Splitting the two workflows that way means the folks that "just want something that works" can benefit from the use of a commercial freemium service, while folks that genuinely prefer to use free and open source tools are also generally willing to be a bit more forgiving of any deficiencies relative to better funded alternatives.
That means my core requirements for the near term solution have changed markedly from those I documented in my withdrawn workflow PEPs: I now merely want to ensure we don't lock ourselves *out* of adding a parallel free-software-needs-free-tools contribution path later. The GitHub-with-a-merge-bot refinement currently being discussed on the core-workflow list clearly meets that criterion (since a merge bot can be updated to accept submissions from multiple sources), and the GitLab EE proposal in PEP 507 arguably does as well (the features we want from GitLab EE that aren't in GitLab CE are relatively minimal, and hence readily implemented on top of CE as an external script if desired).
Cheers, Nick.
P.S. As an analogy I've been working on, consider how folks typically approach creating a welcoming environment for vegetarians & vegans at a community event. Do they:
- serve exclusively vegetarian & vegan dishes?; or
- provide enjoyable vegetarian & vegan dishes, clearly marked as such, while also providing non-vegetarian options?
The latter approach is by far the most common one, as the former risks vocal complaints about the lack of meat dishes from non-vegetarians at the event if your event isn't specifically about vegetarianism and veganism. The equivalent we see in open source workflow design is folks resenting being "forced" to use open source and free software solutions that they consider inferior (or at least unfamiliar) in order to participate, rather than being given a free choice between them and their more familiar proprietary competitors.
By the same taken, nobody would consider a community event that refused to cater to special dietary needs to be a particularly welcoming event, which is why I consider it important to offer a free-software-needs-free-tools friendly approach to contribution.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia