Changes to our Git infrastructure

[Thomas Friedrichsmeier]

Hi,

On Tue, 23 Dec 2014 13:21:37 +0100
Milian Wolff <mail at milianw.de> wrote:
> Here's a list of things that I'd like to have for my workflow, which
> is basically two folded: On one hand, I actively develop new software
> and new features. On the other hand, I spent a considerable amount of
> KDE time reviewing other peoples work.

review requests may have very different motivations. Some projects
(that can afford this) will want to review almost everything. For other
projects, review requests will typically either a) concern rather
complex or touchy changes or b) come from people who are not regular
contributors to the project.

I think your approach of breaking down the problem into different
"points of view" is a great way to get a feel for all sides of the
equation. In addition and in contrast to your "The Developer", I'll
add:

## The Casual Contributor

I am not a regular contributor to project X, but hey, I just played
with this for an afternoon, and I think I have really managed to track
down bug Y that has been annoying me all the time, or implemented the
small but wonderful feature Z that I've been missing for so long.

Now, I am somewhat uncertain on whether this is actually worth
contributing "upstream". My experiences with contributing
to other projects - if any - may not have been too perfect (receiving
no feedback at all, or nothing constructive), so I'm not going to break
my neck on this. But I'll give it a chance, if it seems easy enough:

I want to be able to find reliable information on how to submit my
work, without much searching. I don't care whether the procedure
is the same for this project as for others, as long as there is no
uncertainty about what the procedure is for _this_ project.

I don't want to read through any lengthy or difficult documentation. I
want boiled down, specific instructions. A web-based wizard would be
nice, but the command-line is just as fine, _if_ you can give me
something that I can just copy-and-paste to my console with minimal,
trivial modifications.

At this point I will not be too happy to find out that I should have
taken steps A and B _before_ doing my work. So it would certainly best,
if submission for review would work out-of-the-box with typical starting
points such as an anongit clone. Either way, if I do have to find
out, I started all wrong, I'd like some equally hands-on and concise
instructions on how to correct my mistake.

Naturally, I will have to provide at least my e-mail address, and so
I'm mostly prepared to fill out some easy registration form.
If it can be avoided, I do not want to install or configure anything on
my system, or take any other steps that I may not fully understand,
such as generating SSH keys.

I understand there may be some formal requirements such as coding
style, including tests, or whatever. In fact, as this is all new to
me, I am rather likely to run into some formal issues that would have
been obvious to any regular contributor. So I am prepared to correct and
amend. But please understand that I am not going to put in too much
effort, unless I am reasonably certain that this is actually going
anywhere. So please don't put all formal requirements _first_ by
automatically rejecting my submission on technical reasons. At least
give some human a chance to see my imperfect patch and tell me "nice
idea, but please work on details A and B."

Essentially the same considerations apply, when it comes to tracking
the status of my submission, or refining and re-submitting (or
withdrawing) it. If something cannot be done through the
web-interface, at least the web-interface should tell me the exact
procedure for such actions.

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/20141227/d9279537/attachment.sig>