Topic on Talk:Team Practices Group

Are there any no-brainer practices that all of TPG agrees are beneficial to adopt in 90%+ of relevant situations, and that almost always have a positive return? If so, what are they? To qualify, a practice must be S.M.A.R.T. : Specific, Measurable, Assignable, Realistic, and time-related.

Candidates and areas to consider:

• Don't be a jerk
  • Aware that this is a phrase that calls that specific meta page, I think this might be better summed up as "Let others be heard." As it is, I think "Don't be a jerk" works if you already know what it means, but if you're coming from the vacuum of not knowing best practices then it's only going to elicit a "well, duh," or worse yet, some folks will simply think they are not being a "jerk."
  • The linked page (https://meta.wikimedia.org/wiki/Don%27t_be_a_jerk) specifically addresses the purpose of this mantra as facilitating a space in which people can voice their opinion without being smothered or bullied or peer-pressured[1], as well as one where valid opinions remain valid despite being voiced by a "jerk."
  • TL;DR: Encouraging openmindedness around communication and opinions is, arguably, more effective at preventing "death-by-1000-papercuts" than laying down the law alone. From TPG perspective, this also means facilitating a space in which an outed "jerk" can reflect.
• Appropriate numbers and lengths of meetings
  • (vague, but true)
  • I'm not sure what this means. I recall this page (https://www.mediawiki.org/wiki/Meeting_best_practices_%28including_remote_staff%29)
  • Any meeting over 90 minutes or maybe 2 hours is probably counter-productive. Or at least needs some breaks and structure.
  • All meetings should have agendas and/or definitions of what in necessary for a meeting to be done and successful.
• Minimize waste. Too broad, but drilling in to specific kinds of waste. (NOTE: I think this is an excellent mantra that is hamstrung by the fact that one might not know if they are wasteful until after the fact. Part of iterative improvement, to be sure, but the point remains that it can be challenging the determine if an action that is yet to be taken will be wasteful.)
  • Work that is repeated
    • Prevent two different teams from solving the same problem at the same time without coordination
  • work that is never used
    • Identify when Foundation goals change and terminate orphaned work
    • Finish or abandon what you start
      • (unless there is a reason not to)
        • Is there an example of "unless there is a reason not to"? Seems to me that many unfinished tasks that are later taken up again could probably be refactored or broken up and readdressed before any yuckiness of simply picking up where one left off. It was left unfinished for a reason, so it behooves us to use that knowledge when we return to it.
  • waste from excessive context switching
• Have one, prioritized list of work to be done per work-doing unit (person or team).

For comparison, practices that are probably not simple enough to be no-brainers:

• Aim for an MVP without gold plating
  • (but definitions are debatable)
  • Isn't "avoiding gold-plating" redundant with "MVP"?
• Communicate enough but not too much
  • I like this, but I'm still chewing on it.

Here is a more technically oriented list that I think matches the above definition of no-brainer: http://spot.livejournal.com/308370.html. For example:

* Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]

* Your code has no "make install" [ +20 points of FAIL ]

* Your code doesn't work outside of the source directory [ +30 points of FAIL ]