|WikiProject Computing / Software||(Rated Start-class, Low-importance)|
|WikiProject Business||(Rated Start-class, Low-importance)|
Is high bus factor good or bad ?
It appears that high bus factor means that a lot of people have to be incapacitated to disable a project, which is good. The bus factor in itself is something bad. Think: A bus accident is bad. In a bus accident, the bus is a factor. It has a high "bus factor". In common language you could say that something has a bus factor if the bus factor is a problem. On the other hand, if it is not on the horizon one could probably say, there is no bus factor involved. With this usage a zero bus factor is good and more than zero is bad, which is contrary to the definition.
It would be more straight-forward if the definition followed common logic - high bus factor is bad (which could be problematic to express numerically). Choosing a more positive name could help, e.g. bus survival factor. Any of those are difficult to do if the current usage is spread.
- Usage varies. On the one hand, Coplien and Harrison (reflecting Coplien's early work) write, "Define the truck number as the number of people in the organization who have unique critical domain expertise. You don’t want the truck number to be large, because that means that the probability is large that the loss of any given team member would mean the loss of critical expertise.... Keep the truck number low, thus retaining a small number of key experts with unique knowledge." On the other hand, the Debian reference says, "A bus factor <= 1 is very bad."
- taikedz 126.96.36.199 (talk) 09:26, 8 June 2017 (UTC) :: I'd assert that the contradiction comes from the idea that zero is a valid number - another way of thinking of it is, if everyone has the knowledge, then it would mean taking out the entire team/company to stall the project. This number is not zero; zero could imply that there is no organisation to remove persons from in the first place, or that the knowledge is not required at all. Following that line of logic, bus factor cannot be zero, and a high bus factor is better.
The provided reference doesn't support the claim made for it. It actually says that obviously the bus factor for Linux isn't one, and then goes on to suggest a pointless experiment.
Other Linux trees have been maintained without Linus, the maintenance trees (for 2.4 and 2.2) are maintained without Linus, as are the short-lived stable trees like 2.6.18.x and various trees like AC have thrived without Linus. As have those architecture trees which for whatever reason didn't get frequent merges. If a better reference can't be found, this claim, and arguably the whole article, should go. 188.8.131.52 (talk) 13:25, 19 March 2008 (UTC)
- Actually, I think the reference is to a definition, example of use, and such. A better reference should be sought, though, yes. —AySz88\^-^ 16:28, 1 May 2008 (UTC)
- The article author understands this too so he mentioned that it only is considered for the vanilla tree so I am going to specify the example better in the article. Tempust (talk) 14:38, 23 July 2010 (UTC)
Bad History and opposites
The phrase as a generic unfortunate event dates back to at least 1907 when Joseph Conrad used it in The Secret Agent - So saying that "An early instance of this sort of query was when Michael McLay publicly asked what would happen to the Python language if Guido van Rossum were hit by a bus." is plainly nonsense, that is an example of a late instance, not an early one. (Lawrie (talk) 23:44, 13 May 2015 (UTC))
- Welcome to Wikipedia, and remember to Be bold! I've removed it. Shreevatsa (talk) 20:48, 8 July 2009 (UTC)
- Cross-training reduces the bus factor. For instance, if you are the only person who can update the company's website, and you teach the accountant how to update the website (that's called cross-training), then you just multiplied the bus factor by two. Syced (talk) 04:07, 4 December 2015 (UTC)
Decrease bus factor
Would it be fair to say that the following decrease the bus factor?
- Open source
- Open standards
- Documentation (so a new developer/employee/engineer can join and pickup)
- Developers from different companies/organizations/universities/labs (so layoffs on one company don't affect the employees of the other company)
- Geographically distributed developers
- Developer anonymity (so developers cannot be targeted in attacks)
- Presence of independent developers (not tied to salary, not tied to direction/orders/decisions of higher management)
- Sounds good, feel free to add, be sure that each fact is backed up by a reference. Syced (talk) 04:09, 4 December 2015 (UTC)
There needs to be a formula associated with: "A recent study calculated the bus/truck factor of 133 popular GitHub projects. The results show that most of the systems have a small bus factor (65% have bus factor ≤ 2) and the value is greater than 10 for less than 10% of the systems." — Preceding unsigned comment added by Bostwickenator (talk • contribs) 18:43, 4 May 2016 (UTC)
This article severely lacks illustrations.
I added this picture/label to helps people understand where this metaphor comes from. It is useful to anyone who does not already know the "hit by a bus" cliché. It is especially needed by non-native speakers who might be left wondering whether we are talking about a serial bus.
But an IP reverted it :-/
Hello fellow Wikipedians,
I have just modified one external link on Bus factor. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20120312133941/http://proceedings.esri.com/library/userconf/proc03/p0559.pdf to http://proceedings.esri.com/library/userconf/proc03/p0559.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
You may set the
|checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting
|needhelp= to your help request.
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
If you are unable to use these tools, you may set
|needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.
- Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley.
- Reinholdtsen, Petter (2005-11-11). "Re: Resignation and uploads" (Mailing list).