Hi Franz,
I just want you to know that I have tried the new screen view this week for
my reviews. And I find it very, very useful. Especially the inline comments
in the cover message is super helpful.
Thank you for this info!
And to everybody else: I just want to encourage you to try it out and make
more reviews with it :)
Cheers,
Matthias
2015-02-04 16:09 GMT+01:00 Zieris, Franz <franz.zie...@fu-berlin.de>:
> 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
>
------------------------------------------------------------------------------
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
