[teampractices] Interesting article on over-communication
I thought that there were plenty of good ideas in this article from the Asana founders, so sharing here in the event that you might think so, too: https://blog.asana.com/2015/07/workstyle-communication-internal-memo-from-our-founders/ ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] "Maintenance" vs "New work"
On 5 August 2015 at 14:33, Greg Grossmeier wrote: > > From the notes of our Quarterly Review in July: > > ---quote--- > ==All infrastructure teams, in future quarterly reviews== > --> Lila: for all teams: assess how much of your time goes to: > * supporting others > * new projects > * prototyping / research > want to see a pie chart at end of q > ---quote--- > > I read that as a mandate that we have to follow through on :) > > > https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Infrastructure,_July_2015 > Search for "slide 35" on that page. > > I wasn't there, but the way it's been communicated to me and others > since then is "maintenance vs new work". The Ops team is having a > similar conversation right now as well. See eg: > > https://office.wikimedia.org/wiki/Operations/Operations_Meeting_Notes/TechOps-2015-08-03#Updates Fair enough. My question still stands, but I think the focus of this thread should be on how to fulfil the request which was made of you, so I'll take my questions off-list. Thanks! Dan -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] "Maintenance" vs "New work"
I would guess that it is also related to https://www.mediawiki.org/wiki/Developers/Maintainers and https://www.mediawiki.org/wiki/Upstream_projects and who (if anyone) is tasked with fixing bugs in extensions/code that no existing team/individual is currently (officially) working on. On Wed, Aug 5, 2015 at 2:33 PM, Greg Grossmeier wrote: > > > I'm not certain I understand the need to draw a distinction between > > maintenance and new work. I prefer to think purely in terms of what work > is > > the most strategic in terms of achieving our mission; for the purposes of > > that, whether work is "maintenance work" or "new work" is irrelevant, as > > all that matters is if the work is the most strategic. Is there any > > background on why you are being asked to make this distinction? > > From the notes of our Quarterly Review in July: > > ---quote--- > ==All infrastructure teams, in future quarterly reviews== > --> Lila: for all teams: assess how much of your time goes to: > * supporting others > * new projects > * prototyping / research > want to see a pie chart at end of q > ---quote--- > > I read that as a mandate that we have to follow through on :) > > > https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Infrastructure,_July_2015 > Search for "slide 35" on that page. > > I wasn't there, but the way it's been communicated to me and others > since then is "maintenance vs new work". The Ops team is having a > similar conversation right now as well. See eg: > > https://office.wikimedia.org/wiki/Operations/Operations_Meeting_Notes/TechOps-2015-08-03#Updates > > Greg > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > -- Nick Wilson (Quiddity) Community Liaison, Product Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] "Maintenance" vs "New work"
> I'm not certain I understand the need to draw a distinction between > maintenance and new work. I prefer to think purely in terms of what work is > the most strategic in terms of achieving our mission; for the purposes of > that, whether work is "maintenance work" or "new work" is irrelevant, as > all that matters is if the work is the most strategic. Is there any > background on why you are being asked to make this distinction? From the notes of our Quarterly Review in July: ---quote--- ==All infrastructure teams, in future quarterly reviews== --> Lila: for all teams: assess how much of your time goes to: * supporting others * new projects * prototyping / research want to see a pie chart at end of q ---quote--- I read that as a mandate that we have to follow through on :) https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Infrastructure,_July_2015 Search for "slide 35" on that page. I wasn't there, but the way it's been communicated to me and others since then is "maintenance vs new work". The Ops team is having a similar conversation right now as well. See eg: https://office.wikimedia.org/wiki/Operations/Operations_Meeting_Notes/TechOps-2015-08-03#Updates Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Defining "Interrupt" work
On Wed, Aug 5, 2015 at 12:31 PM, Joel Aufrecht wrote: > I'm working on a definition of "interrupt" work that we could standardize > and measure across the Foundation. The purpose is to inform planning; in > particular, we probably have a lot of teams thinking they can, or being > asked to, complete a certain amount of new work, without fully taking into > account the amount of maintenance work that will continue arriving. > > I'm starting by collecting information and opinions. Here's what I have: > > 1) Terry has three buckets, but I don't have their exact names or > definitions > > 2) I've been thinking roughly, "work that has to be done to maintain > existing products and services at their current level of > functionality/performance/success". > > 2a) The question of "success" is interesting; if a product starts losing > market share, is work to keep market share up "interrupt"? I think it > isn't, and the "output vs outcome" divide applies here. If the output (a > service being available) breaks, fixing that is interrupt, but if an output > becomes less popular, making it more appealing is not interrupt. > > 2b) What about patching and upgrades? Is a patch "interrupt", but an > upgrade to support a new version of Windows not? > > 3) Some notion of planned vs unplanned? Is the essence of interrupt work > that it's unplanned? Or are "maintenance work" and "unplanned work" > distinct; it just happens that a much bigger percentage of maintenance work > is unplanned compared to new-functionality work? > > 4) Is there any definition from MPL work? > > 5) Are any teams other than VE experimenting with this distinction in their > backlogs? > > (Tracking: https://phabricator.wikimedia.org/T107824) As someone who mostly does "interrupt" work, my definition for it is "work that you didn't know when you started your day that you would have to do". For me this is mostly must fix bugs in production, beta cluster and/or mediawiki-vagrant combined with tasks that were blocked waiting on some other entity that are suddenly in need of further attention. My personal historical experience both here and at prior jobs is that planning for this is a matter of heuristics at best. Having teams/individuals track the amount of work of this type that they experience for a month or two can lead to a baseline estimate of the number of hours per week it typically takes. Bryan -- Bryan Davis Wikimedia Foundation [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Defining "Interrupt" work
So I would say the buckets are about rat but I would certainly welcome some feedback on how we make definitions that are good for engineering.. If I use my house analogy.. Bucket 1 is CORE - It is paying the mortgage, the property tax and copying with HOA rules and local ordinance and building codes Bucket 2 is Maintenance - Painting the house every 5 years, putting a new roof on every 20 years, cutting the grace one a week.. All of this you can postpone but typically there is a cost increase to not doing that you eventually have to pay for later. EG it will take longer to get the lawn back in shape if you let beth grass go to seed or the painting of a house takes longer if you have to replace woodwork etc due to rot. Bucket 2 - Investment / new projects - This is remodeling the bathroom.. highly optional but makes like easier and could improve the overall value of the house.. Be interesting to get engineering analogy for this.. - Thoughts? Interrupt work would, to me, mean "unplanned". Examples are.. a hail storm that damages the roof.. a tree that falls over... Does that help any? On Wed, Aug 5, 2015 at 1:05 PM, Kevin Smith wrote: > I think I understood Terry's buckets to be: > > >1. Keep the lights on and servers running, assuming nothing external >impacts them. >2. Respond to external events, such as security patches and library >upgrades. >3. Innovation. > > I believe DStrine recently created an "Unplanned" tag in phabricator, > which certainly sounds related. In that case, I believe the definition was > "Work we added to this sprint after this sprint started." Which seems like > an entirely reasonable definition, for teams doing timeboxed iterations as > in Scrum. > > I think my existing discomfort with the conversations so far about > "interrupt" work boils down to not knowing if it is "unplanned" work, > "externally triggered" work, or "not part of our long-term goals" work. Or > some combination of those. > > > > > > Kevin Smith > Agile Coach > Wikimedia Foundation > > > > *Imagine a world in which every single human being can freely share in the > sum of all knowledge. That's our commitment. Help us make it a reality.* > > On Wed, Aug 5, 2015 at 11:31 AM, Joel Aufrecht > wrote: > >> I'm working on a definition of "interrupt" work that we could standardize >> and measure across the Foundation. The purpose is to inform planning; in >> particular, we probably have a lot of teams thinking they can, or being >> asked to, complete a certain amount of new work, without fully taking into >> account the amount of maintenance work that will continue arriving. >> >> I'm starting by collecting information and opinions. Here's what I have: >> >> 1) Terry has three buckets, but I don't have their exact names or >> definitions >> >> 2) I've been thinking roughly, "work that has to be done to maintain >> existing products and services at their current level of >> functionality/performance/success". >> >> 2a) The question of "success" is interesting; if a product starts losing >> market share, is work to keep market share up "interrupt"? I think it >> isn't, and the "output vs outcome" divide applies here. If the output (a >> service being available) breaks, fixing that is interrupt, but if an output >> becomes less popular, making it more appealing is not interrupt. >> >> 2b) What about patching and upgrades? Is a patch "interrupt", but an >> upgrade to support a new version of Windows not? >> >> 3) Some notion of planned vs unplanned? Is the essence of interrupt work >> that it's unplanned? Or are "maintenance work" and "unplanned work" >> distinct; it just happens that a much bigger percentage of maintenance work >> is unplanned compared to new-functionality work? >> >> 4) Is there any definition from MPL work? >> >> 5) Are any teams other than VE experimenting with this distinction in >> their backlogs? >> >> (Tracking: https://phabricator.wikimedia.org/T107824) >> >> >> *Joel Aufrecht* >> Team Practices Group >> Wikimedia Foundation >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > -- Terence (Terry) Gilbey Chief Operating Officer Wikimedia Foundation 149 New Montgomery Street San Francisco, CA 94105 (626) 222 5230 tgil...@wikimedia.org ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] "Maintenance" vs "New work"
On 5 August 2015 at 12:10, Greg Grossmeier wrote: > > Are there any teams at WMF who already have these two buckets defined? > What are your definitions? > Things like restarting the ElasticSearch cluster, and upgrading the ElasticSearch cluster, are maintenance work for my team. I guess the criteria I use is anything which keep search ticking, but doesn't related directly to our goals is "maintenance work". I'm not certain I understand the need to draw a distinction between maintenance and new work. I prefer to think purely in terms of what work is the most strategic in terms of achieving our mission; for the purposes of that, whether work is "maintenance work" or "new work" is irrelevant, as all that matters is if the work is the most strategic. Is there any background on why you are being asked to make this distinction? Dan -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] "Maintenance" vs "New work"
Distinguishing between "maintenance" and "new" work seems very gray to me. Roughly as gray as "bug" vs. "improvement". I guess a working definition for us right now might be: Either it's part of a project in the MPL, or it is "maintenance", or there's a reasonable chance you shouldn't be doing it. Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.* On Wed, Aug 5, 2015 at 12:10 PM, Greg Grossmeier wrote: > Following on to Joel's message about "interrupt" work, I'd like to start > a thread on maintenance vs new work. > > Context: In the last round of quarterly reviews it was requested that > teams be prepared to give an idea of the proportion of work that falls > into "maintenance" vs "new work". > > Now, the hard part: what are the defining characteristics of those > options? How can we quickly lock at a task/bit of work and put it into > one of them? > > Are there any teams at WMF who already have these two buckets defined? > What are your definitions? > > Greg > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Defining "Interrupt" work
I think I understood Terry's buckets to be: 1. Keep the lights on and servers running, assuming nothing external impacts them. 2. Respond to external events, such as security patches and library upgrades. 3. Innovation. I believe DStrine recently created an "Unplanned" tag in phabricator, which certainly sounds related. In that case, I believe the definition was "Work we added to this sprint after this sprint started." Which seems like an entirely reasonable definition, for teams doing timeboxed iterations as in Scrum. I think my existing discomfort with the conversations so far about "interrupt" work boils down to not knowing if it is "unplanned" work, "externally triggered" work, or "not part of our long-term goals" work. Or some combination of those. Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.* On Wed, Aug 5, 2015 at 11:31 AM, Joel Aufrecht wrote: > I'm working on a definition of "interrupt" work that we could standardize > and measure across the Foundation. The purpose is to inform planning; in > particular, we probably have a lot of teams thinking they can, or being > asked to, complete a certain amount of new work, without fully taking into > account the amount of maintenance work that will continue arriving. > > I'm starting by collecting information and opinions. Here's what I have: > > 1) Terry has three buckets, but I don't have their exact names or > definitions > > 2) I've been thinking roughly, "work that has to be done to maintain > existing products and services at their current level of > functionality/performance/success". > > 2a) The question of "success" is interesting; if a product starts losing > market share, is work to keep market share up "interrupt"? I think it > isn't, and the "output vs outcome" divide applies here. If the output (a > service being available) breaks, fixing that is interrupt, but if an output > becomes less popular, making it more appealing is not interrupt. > > 2b) What about patching and upgrades? Is a patch "interrupt", but an > upgrade to support a new version of Windows not? > > 3) Some notion of planned vs unplanned? Is the essence of interrupt work > that it's unplanned? Or are "maintenance work" and "unplanned work" > distinct; it just happens that a much bigger percentage of maintenance work > is unplanned compared to new-functionality work? > > 4) Is there any definition from MPL work? > > 5) Are any teams other than VE experimenting with this distinction in > their backlogs? > > (Tracking: https://phabricator.wikimedia.org/T107824) > > > *Joel Aufrecht* > Team Practices Group > Wikimedia Foundation > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day
On Wed, 2015-08-05 at 08:16 -0700, Greg Grossmeier wrote: > e="13:43:12 +0200"> > > I would suggest doing a post-release day (branch cuts happen on Tuesday, so > > maybe use Wed or Thu) so that if we merge a lot of patches we'll have as > > much time as possible until the next release cut to test stuff on the beta > > cluster. > > That's a great point, Joaquin, and I agree. If we see a ton of > random-ish patches merged in random places in our code base it'd be a > good idea to have a bit more time to test on Beta Cluster. Quim already covered why the initial idea proposed Friday (fun character, getting out of usual habits a bit) but "more testing" is a very convincing reason. So let's target Wednesday, September 23th. In any case, it's all about making sure that people actually do manage to break out a bit of their "daily routine" and dedicate the day to reviewing patches, instead of "I'll first have to do my daily standup and then I need to finish that stuff from yesterday and maybe later in the afternoon I might get to that patch review thingy". You get me. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day
On Tue, 2015-08-04 at 16:58 -0700, Arthur Richards wrote: > Couple of questions - are there plans to document/track > 'unmaintained' repositories? That sounds pretty related to the discussion in https://phabricator.wikimedia.org/T102920 (input welcome!). AFAIK we don't even have a general "consensus" how to define "unmaintained". :-/ Are you basically after automatically updated stats that state "Repository XYZ saw the last merged code change on -MM-DD" (and hopefully exclude merged translation updates)? Only thing I know is: We do have some activity charts per repo at http://korma.wmflabs.org/browser/scm-repos.html but I have no idea what that list is sorted by or if it is sortable. Feel free to file a request under "Analytics-Tech-community-metrics" in Phabricator. > Further, are there additional metrics that can come out of the GCD > that we don't get out of Korma that would be useful information to > have (eg patches to non-WMF maintained repos vs patches to WMF > maintained repos)? I'm not aware of any (machine-readable?) "repositories maintained by WMF folks" information available anywhere. I am/was only aware of files which list the (MW extension) repos deployed on WMF servers. Those were once upon a time listed in https://git.wikimedia.org/raw/mediawiki%2ftools%2frelease.git/HEAD/make-wmf-branch%2fdefault.conf and now that I check I see they are not anymore. Hmm hmm. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day
Generally: Thanks for all the feedback in this thread. Appreciated! On Tue, 2015-08-04 at 14:50 -0400, Kristen Lans wrote: > Overall seems fine to me, especially given that this is an > experiment. As with all experiments, I wonder: how will you know you > are successful? I see things like "All open changesets submitted by > *new* volunteers (as opposed to new changesets alone) in the last > three months should have at least one review.". For the specific example, data in Korma might be helpful to evaluate: http://korma.wmflabs.org/browser/code_contrib_new_gone.html (However it's unclear to me how often that is updated; also see https://phabricator.wikimedia.org/T102112 marked as a blocker) > Probably be good to be really clear and explicit about what success > looks like for this event in order to evaluate whether or not it will > be an ongoing thing. +1 on "we need metrics for evaluation of success" That's an area I still need to do more homework. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
[teampractices] "Maintenance" vs "New work"
Following on to Joel's message about "interrupt" work, I'd like to start a thread on maintenance vs new work. Context: In the last round of quarterly reviews it was requested that teams be prepared to give an idea of the proportion of work that falls into "maintenance" vs "new work". Now, the hard part: what are the defining characteristics of those options? How can we quickly lock at a task/bit of work and put it into one of them? Are there any teams at WMF who already have these two buckets defined? What are your definitions? Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
[teampractices] Defining "Interrupt" work
I'm working on a definition of "interrupt" work that we could standardize and measure across the Foundation. The purpose is to inform planning; in particular, we probably have a lot of teams thinking they can, or being asked to, complete a certain amount of new work, without fully taking into account the amount of maintenance work that will continue arriving. I'm starting by collecting information and opinions. Here's what I have: 1) Terry has three buckets, but I don't have their exact names or definitions 2) I've been thinking roughly, "work that has to be done to maintain existing products and services at their current level of functionality/performance/success". 2a) The question of "success" is interesting; if a product starts losing market share, is work to keep market share up "interrupt"? I think it isn't, and the "output vs outcome" divide applies here. If the output (a service being available) breaks, fixing that is interrupt, but if an output becomes less popular, making it more appealing is not interrupt. 2b) What about patching and upgrades? Is a patch "interrupt", but an upgrade to support a new version of Windows not? 3) Some notion of planned vs unplanned? Is the essence of interrupt work that it's unplanned? Or are "maintenance work" and "unplanned work" distinct; it just happens that a much bigger percentage of maintenance work is unplanned compared to new-functionality work? 4) Is there any definition from MPL work? 5) Are any teams other than VE experimenting with this distinction in their backlogs? (Tracking: https://phabricator.wikimedia.org/T107824) *Joel Aufrecht* Team Practices Group Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day
> I would suggest doing a post-release day (branch cuts happen on Tuesday, so > maybe use Wed or Thu) so that if we merge a lot of patches we'll have as > much time as possible until the next release cut to test stuff on the beta > cluster. That's a great point, Joaquin, and I agree. If we see a ton of random-ish patches merged in random places in our code base it'd be a good idea to have a bit more time to test on Beta Cluster. -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Hazards of back-estimating backlog story points
On Tue, 2015-08-04 at 16:11 -0700, Joel Aufrecht wrote: > Because VE has around 5000 open tasks and only 800 estimated tasks https://phabricator.wikimedia.org/maniphest/query/nvSn_H7WxUyO/#R and https://phabricator.wikimedia.org/maniphest/report/project/ both state that there are 1328 open tasks in the "VisualEditor" project so I'm curious what calculation method the number 5000 is based on. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day
I would suggest doing a post-release day (branch cuts happen on Tuesday, so maybe use Wed or Thu) so that if we merge a lot of patches we'll have as much time as possible until the next release cut to test stuff on the beta cluster. This is a great idea, and we need to think of continuous efforts to educate wmf developers about better code review practices. I recommend reading this email Sam (phuedx) sent in June to mobile-l: https://lists.wikimedia.org/pipermail/mobile-l/2015-June/009357.html And watch the talk if you are interested. Hey y'all, > I watch a lot of talks in my downtime. I even post the ones I like to a > Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a > Strong Code Review Culture" from RailsConf 2015 in particular because it's > relevant to the conversations that the Reading Web team are having around > process and quality. You can watch the talk on YouTube [1] and, if you're > keen, you can read the paper that's referenced over at Microsoft Research > [2]. > I particularly like the challenge of providing two paragraphs of context > in a commit message – to introduce the problem and your solution – and > trying to overcome negativity bias in written communication* by offering > compliments whenever possible and asking, not telling, while providing > critical feedback. > I hope you enjoy the talk as much as I did. > –Sam > [0] http://sometalks.tumblr.com/ > [1] https://www.youtube.com/watch?v=PJjmw9TRB7s > [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283 > * The speaker said "research has shown" but I didn't see a citation > *Notes (width added emphasis)* > >- Code review isn't for catching bugs > > >- "Expectations, Outcomes, and Challenges of Modern Code Review" > > >- Chief benefits of code review: > > >- Knowledge transfer > > >- Increased team awareness > > >- Finding alternative solutions > > >- Code review is "the discipline of explaining your code to your peers" > > >- Process is more important than the result > > >- Goes on to define code review as "the discipline of discussing your >code with your peers" > > >- If we get better at code review, then we'll get better at >communicating technically as a team > > Rules of Engagement > >- As an author, provide context > > >- "If content is king, then context is God" > > >- *In a pull request (patch set) the code is the content and the >commit message is the context* > > >- Provide sufficient context - bring the reviewer up to speed with >what you've been doing in the past X hours > > >- *Challenge: provide at least two paragraphs of context in your >commit message* > > >- This additional context lives on in the commit history whereas links >to issue trackers might not > > >- As a reviewer, ask questions rather than making demands > > >- Research has shown that there's a negativity bias in written >communication. *Offer compliments whenever you can* > > >- *When you need to provide critical feedback, ask, don't tell*, e.g. >"extract a service to reduce some of this duplication" could be formulated >as "what do you think about extracting a service to reduce some of this >duplication?" > > >- "Did you consider?", "can you clarify?" > > >- "Why didn't you just..." is framed negatively and includes the word >just > > >- Use the Socratic method: asking and answering questions to stimulate >critical thinking and to illuminate ideas > > Insist on high quality reviews, but agree to disagree > >- Conflict is good. *Conflict drives a higher standard of coding >provided there's healthy debate* > > >- Everyone has a minimum bar to entry for quality. Once that bar is >met, then everything else is a trade-off > > >- Reasonable people disagree all the time > > >- Review what's important to you > > >- SRP (Single Responsibility Principle) (the S from SOLID) > > >- Naming > > >- Complexity > > >- Test Coverage > > >- ... (whatever else you're comfortable in giving feedback on) > > >- What about style? > > >- Style is important > > >- "People who received style comments on their code perceived that >review negatively" > > >- Adopt a styleguide > > > Benefits of a Strong Code Review Culture > >- Better code > > >- Better developers through constant knowledge transfer > > >- Team ownership of code, which leads to fewer silos > > >- Healthy debate > > On Wed, Aug 5, 2015 at 1:58 AM, Arthur Richards wrote: > Generally looks good to me. > > Couple of questions - are there plans to document/track 'unmaintained' > repositories? Further, are there additional metrics that can come out of > the GCD that we don't get out of Korma that would be useful information to > have (eg patches to non-WMF maintained repos vs patches to WMF maintained > repos)? > > On Tue, Aug 4, 2015 at 1:45 PM, Quim Gil
