Document GitLab as the only way to contribute to Samba?

[William Brown]

> On 11 Sep 2019, at 11:34, Martin Schwenke via samba-technical <samba-technical at lists.samba.org> wrote:
> 
> On Fri, 06 Sep 2019 16:54:17 +1200, Andrew Bartlett via samba-technical
> <samba-technical at lists.samba.org> wrote:
> 
>> On Fri, 2019-06-28 at 00:31 +0200, Michael Adam wrote:
>>> 
>>> I personally think that mail list reviews do have some advantages
>>> but the gitlab system also has several advantages.
>>> 
>>> So I would in general be fine with the change.
>>> 
>>> Not sure if it would help to first declare the ML submissions
>>> deprecated and in a second step declare gitlab the only way to
>>> submit?  
>> 
>> So, after all that and some water under the bridge, can we please agree
>> to go ahead and make that change, for the sake of clarity and
>> consistency?
>> 
>> I would document it as (roughly):
>> 
>> - GitLab is the strongly perferred method to contribute to Samba. 
>> - Patches mailed to the mailing list may still be considered, but
>> require additional work on the part of Samba Team members so are
>> discouraged. 
>> 
>> If you are interested in reviewing patches submitted to Samba, please
>> ensure you have a gitlab.com account and are watching our public gitlab
>> repository. 
> 
> Sorry, but NACK.
> 
> Samba is a Free Software project.  While that is true we must not
> mandate a proprietary platform as the only way of contributing.  Nor
> should we discourage contributions that are not made via a proprietary
> platform.

I don't think that Andrew is saying "this is the only way to contribute", and maybe this is a miswording?

I would expect that this is the *default* method of contribution because it makes the new contributor experience easier and smoother. Which is really important if you want to bring in new people to a project, to have that process really easy and accessible. Lowering the barrier to entry is a good thing because you broaden your talent pool, and giving that talent a positive first contribution experience means they are more likely to stay around. 

> 
> There are many reasons why a new contributor may be unable to use
> GitLab, including:
> 
> * They may not agree with the terms of service
> 
> * They may not wish to take the time to setup an account and be added
>  to the required project
> 
> * They may find the user interface unusable
> 
> * They may not have (reliable) web access
> 
> They may still be able to make very worthwhile contributions.
> 
> Ironically, Git - and, therefore, GitLab - exists because the founder of
> the Samba project did not think it reasonable for a proprietary product
> to be mandated for development on another project.
> 
> More pragmatically, GitLab may go away, so we should keep our options
> not only open but also active.
> 
> We should continue to encourage this mailing list as an option for
> contributing to Samba.  If a reviewer prefers seeing a GitLab CI
> pipeline pass before they look at code then, if a mailing list
> contribution sounds interesting, they can save the patch, run "git am"
> and push the resulting branch to GitLab GI in less than a minute or 2.
> They can then reply to the contributor saying "looks interesting,
> waiting for GitLab CI pipeline <url> to complete".  This mailing list
> isn't so busy that hand-processing a few contributions will swamp any
> reviewer's time.

Every barrier that exists for a reviewer to provide "review feedback" means that it will create a mental block/energy block which some people won't overcome. It's hard enough to get people to review a patch, let alone expecting reviewers to do additional work which could be automated by a system like gitlab. 

Just in my experience, from the 389 ds project, we went from patch files on mailing list, to patches on a ticket tracker (with inline comments), then to PR's. Since doing this our developer work load is lighter, and we are now seeing better community engagement and contribution, better quality reviews due to inline commenting, less git mistakes, better engagement with our CI, and more. At the time I was very against the PR workflow, but slowly I realised that there were technical benefits for other people - it wasn't just about what I wanted and what I was used to, but about helping other people be more productive in a project that I take so much pride in. To see that people are now actually doing once-off pull requests to 389 really makes me happy and excited for our future. 

In other words, by shifting boring manual labor to a tool like gitlab, we were able to focus on what mattered - (re)building a community, and encouraging development and improvement. 

I think that this is a really positive change for the samba project and is a really positive step to opening wider doors to the samba developers of the future. 

> 
> Sorry, mate!  This is a hill I'm willing to die on...
> 
> peace & happiness,
> martin

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs