Hi again, I just came across a partial solution for another problem (unlisted in the original e-mail below): It's difficult to keep track of the discussions.
Even with our current Gerrit version (2.8), everyone can switch to the so-called "New Screen" for viewing changes. See here [1] how it looks and how it helps keeping track. See here [2] how you enable this feature. Cheers, Franz [1] https://www.dropbox.com/s/zxenw6ho3qdlhpl/gerrit_new_settings1.png?dl=0 [2] https://www.dropbox.com/s/a96md64b0huh8vh/gerrit_new_settings2.png?dl=0 -----Original Message----- From: Zieris, Franz [mailto:franz.zie...@fu-berlin.de] Sent: Monday, February 02, 2015 6:57 PM To: dpp-devel@lists.sourceforge.net Subject: [DPP-Devel] Today's discussion on our review process Dear developers, you probably noticed that our current review process has some seemingly paradoxical properties: * There are plenty of developers who want to contribute to the Saros code base, all of which are also potential reviewers. * There are plenty of open patches in the review system. * The average review time (first patch set uploaded until submission) of a patch is either extremely short (barely the time Jenkins takes to build it, thus no actual review) or rather large (several days, weeks or even months). Today, some of us (Christian, Matthias, Arsenij, Arndt, Bastian, Holger, and myself) analyzed and discussed this matter. First, we collected all the positive aspects code reviewing can have and which we deem desirable in the Saros context: * It offers multiple perspectives on the code and code changes, such as avoiding stupid mistakes, finding valuable small improvements as well as better design decisions, and achieving a very high documentation quality. * It fosters knowledge transfer between the developers since you come in touch with a multitude of foreign code. * You are motivated since you receive immediate and frequent feedback on your work early-on. * You are encouraged to adapt an incremental working style. * It improves the overall team spirit. Then, we collected anecdotes and recurring themes of what goes wrong in our reviews, i.e. where any of the above benefits are impaired -- unfortunately, too numerous and too interconnected to list them here. So I will concentrate on the results: We produced many ideas on what to do better, but decided to work on one at a time. We chose to introduce the following rule: If you review a patch, let the author know what you think of it. Even if you have no substantial points to add to the things others already said. Sounds simple? It is. Sounds trivial? It is not: In both cases (not repeating a positive vote, not repeating a negative vote) the author will wait for more responses to come, thus slowing down the review process as a whole. In the positive case, because one +1 is not enough for submission. In the negative case, because there might be another reviewer-to-be out there who could find even more problems, which can be addressed in one patch set together with the issues already reported. I added this point to our review process description [1] which I restructured a little bit and cleaned out same residues from the pre-Gerrit era. We will discuss the effect of this new rule in three weeks, on 23rd February, and we will possibly also decide on further adjustments in our process. If you have any input on this matter, please let me know before this date (either in private or by CC'ing this mailing list). Cheers, Franz [1] http://www.saros-project.org/review ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
