It's the new year, and in light of the recent poll about which devs are working on what, let me make another, albeit vaguely macabre, suggestion:
If you're a developer, or other staffer, can the people around you pick up the pieces if you get hit by a bus? How badly will it impact delivery and delivery scheduling of what you're working on?
Is the institutional knowledge about our architecture and plans sufficiently well documented and spread out that we don't have anyone with an unreasonably high bus factor?
Cheers, -- jra
On 01/09/2013 08:56 PM, Jay Ashworth wrote:
It's the new year, and in light of the recent poll about which devs are working on what, let me make another, albeit vaguely macabre, suggestion:
If you're a developer, or other staffer, can the people around you pick up the pieces if you get hit by a bus? How badly will it impact delivery and delivery scheduling of what you're working on?
This is a good reminder of yet another reason to document things.
Is the institutional knowledge about our architecture and plans sufficiently well documented and spread out that we don't have anyone with an unreasonably high bus factor?
However, high bus factor is good. As Wikipedia states, "The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed".
The higher this is, the less likely the project actually would be derailed for such a reason.
Matt Flaschen
On 01/09/2013 10:24 PM, Matthew Flaschen wrote:
On 01/09/2013 08:56 PM, Jay Ashworth wrote:
It's the new year, and in light of the recent poll about which devs are working on what, let me make another, albeit vaguely macabre, suggestion:
If you're a developer, or other staffer, can the people around you pick up the pieces if you get hit by a bus? How badly will it impact delivery and delivery scheduling of what you're working on?
This is a good reminder of yet another reason to document things.
Is the institutional knowledge about our architecture and plans sufficiently well documented and spread out that we don't have anyone with an unreasonably high bus factor?
However, high bus factor is good. As Wikipedia states, "The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed".
The higher this is, the less likely the project actually would be derailed for such a reason.
Matt Flaschen
I created https://www.mediawiki.org/wiki/Developers/Maintainers partially to document the activities (highlighted in red) where our bus factor is dangerously low. And it's one of the reasons why LevelUp is useful; it's a systematic way to improve bus factor. Code reviewing is not just a gate to keep bugs out of code, but a social step, to get a second set of eyes on code, and to spread knowledge around. Code review is a much more natural way, rather than sending out a mass email, to keep colleagues informed about changes to areas of their interest. (Of course, if someone creates a new test methodology or wants to do something big, there should be appropriate communication about that.)
Chris Steipp and I have had some success running documentation sprints where we improve very specific bits of mediawiki.org, and I would love to help others do similarly.
wikitech-l@lists.wikimedia.org