Hi, On Tue, 23 Dec 2014 13:21:37 +0100 Milian Wolff <m...@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
signature.asc
Description: PGP signature
