Changes to our Git infrastructure

[Thomas Friedrichsmeier]

Hi,

On Mon, 05 Jan 2015 10:37:24 +0100
Jan Kundrát <jkt at kde.org> wrote:
> On Sunday, 4 January 2015 13:21:12 CEST, Thomas Friedrichsmeier wrote:
> > True, but don't forget about the other side of the story:
> > - potential contributors will have to learn more stuff, before they
> >   can even _start_ contributing, which may be a real turn-off in
> > some cases.
> 
> That's a valid concern, so the core question is whether this scenario:
> 
> - make changes
> - make a commit
> - push that commit

Well, I think we're still not at this point of the discussion, really.
Nor have I read enough to actually form a reasoned opinion on your
favorite tool, so far. But I do think you're skipping a few required
steps, here (either that, or my reading so far has been misleading).

> is any more complex than:
> 
> - make changes
> - create a diff
> - upload that diff via a browser.
> 
> I have to admit I have no idea which one is *really* easier for a
> total newbie, and which one is easier for an average contributor.

I think there is an easy test for this (well, not a real test, but a
useful initial heuristic): Can you explain exactly how to submit a
patch for your project
- to someone without prior knowledge of the tools involved
- without assuming the required tools/keys/accounts are already set up
- without any further reading
- covering all required steps in sufficient detail
in no more than 2000 words, or (if it's based on a web-wizard) in less
than 20 minutes?

I'm not talking about documenting everything, of course. Once people
start wondering about advanced features or just background information,
they can certainly be expected to dive in, deeper. Just enough to
actually be able to submit a patch in roughly the way you are supposed
to. For such an initial encounter, I think an investment of ~20 minutes
for the submission procedure is the absolute maximum you can be asking
for. Everything above that is pretty much signaling that you don't
actually want any external contributions, IMO.

Note that I don't actually know what the answer is to this WRT gerrit.

> > Your project's situation may be very different from mine.
> > Personally, I'm much more worried about keeping the entry barrier
> > as low as possible, than about reducing the amount of effort that I
> > have to put into supporting and educating contributors.
> 
> That's also a possibility. However, in my experience with Gerrit, GCI 
> students (which are kids aged 12-18, IIRC) were able to upload
> patches without substantial problems. That's despite our rudimentary
> state of KDE-specific documentation, and Gerrit having a "oh no,
> let's run away from that beast" reputation. In short, I think that
> there's actually a solution which can be both a low enough barier to
> entry *and* help maintainers do their job easier.

Well, arguably, once you are a GCI student, it's too late to run away
from the beast. But well, that's the problem in the first place: We
just don't get to talk to those, we scared off.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150105/59e72853/attachment.sig>