[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: We need to enable auto close in github pull requests
From:       Milian Wolff <mail () milianw ! de>
Date:       2017-05-02 14:42:47
Message-ID: 2200974.cgV4sm6gOt () milian-kdab2
[Download RAW message or body]

On Friday, April 28, 2017 3:09:51 PM CEST Albert Astals Cid wrote:
> El divendres, 28 d'abril de 2017, a les 11:56:26 CEST, Milian Wolff va
> 
> escriure:
> > On Donnerstag, 27. April 2017 17:15:44 CEST Albert Astals Cid wrote:
> > > El dilluns, 13 de març de 2017, a les 0:31:37 CEST, Albert Astals Cid va
> > > 
> > > escriure:
> > > > Looking at https://github.com/pulls?q=is%3Apr+org%3Akde+is%3Aopen
> > > > makes
> > > > me
> > > > very sad seeing how there's people that want to contribute but will
> > > > never
> > > > get an answer.
> > > > 
> > > > Even if you click to those 109 closed you can see how there are some
> > > > that
> > > > are from people that clearly got fed up from waiting.
> > > > 
> > > > Please people that administer the github account ( ¿Riddell?) make that
> > > > happen
> > > 
> > > I made it happen.
> > > 
> > > I'm running https://github.com/tsdgeos/nopullrequests/ in a free
> > > appspot.com instance and it will autoclose pull requests of projects
> > > immediately.
> > > 
> > > Example: https://github.com/KDE/dummy/pull/1
> > 
> > As exemplified here:
> > 
> > https://github.com/KDE/heaptrack/pull/9
> > 
> > I want to request that heaptrack is excluded from this bot. I do get mail
> > notifications for heaptrack pull requests and took care of them in the
> > past. I want to keep this contribution channel open. I see no point in
> > not doing so for an extragear repo I maintain myself.
> 
> There are various reasons for which I think we should apply this to all the
> projects (i.e. not accept your request to exclude heaptrack from the bot):
> 
> ** Makes for easier handling **
> The code we're using for the bot is per repo, but adding exceptions means
> people have to actually keep a list of which repo is supposed to be enabled
> and which not, that is extra work.

In my eyes this is less important than actually getting contributions.

> ** Makes for better collaboration **
> Yes, you are looking at github, but are other people interested in
> contributing to heaptrack? By not using the common tools you're alienating
> them, losing their probably valuable reviews or forcing them to use some
> extra tools that are not the ones KDE as agreed to use. And yes there may
> not be more people interested in contributing to heaptrack at the moment,
> but by adding extra hurdles you are making it harder than needed to get a
> frequent collaborator.

I don't understand this. I've used GitHub *in addition* to phabricator. And 
the heaptrack README actually points to phabricator, yet still people publish 
stuff via GitHub. Why would accepting those contributions alienate anyone?

Or do you mean reviewers? Well, as you say - if there'd be others interested 
in maintaining it, you could actually make a point here. But since there are 
none, this is just hot air. Also see below.

> ** Makes for a more consistent experience **
> Everyone gets to contribute through the same paths to our code

So that would mean:

- I must not accept patches sent to me directly via email
- I must not accept patches attached to bugs
- I must not accept patches sent to me via pastebin links on IRC
- ...

Why? If they are uncontroversial I as a maintainer feel like I have the right 
to accept them without going through the bureaucracy of phabricator.

And again: Just like GitHub, all of the above methods don't happen often. But 
I don't see *any* point in forbidding them. If I actually need more input I 
can always delegate to phabricator.

> ** Is more future proof **
> Eventually, you will get tired of heaptrack, this means that eventually
> you'll stop reading github pull requests. It is true that when you get
> tired you will also stop reading phabricator pull requests, but at least
> they will be in places the rest of KDE will look at when they are bored
> instead of lying dead in github.

That is a valid point. But, as you say, it also affects phabricator and all 
other channels we have.

> So what I am asking you is to be flexible and relinquish your request that I
> agree it may seem like it is better for you personally but makes it a bit
> harder for the rest of us.

I still disagree with this. Au contraire, I'd say you should be flexible here, 
not me. 

Again: I personally see the ease of contribution as the most important aspect 
of a FOSS project. Making it harder for people for reasons that are pretty 
much irrelevant to them drives them away. I don't like that.

Bye

-- 
Milian Wolff
mail@milianw.de
http://milianw.de
[prev in list] [next in list] [prev in thread] [next in thread]