Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io.js Truck Factor #2345

Closed
gavelino opened this issue Aug 10, 2015 · 3 comments
Closed

io.js Truck Factor #2345

gavelino opened this issue Aug 10, 2015 · 3 comments
Labels
invalid Issues and PRs that are invalid.

Comments

@gavelino
Copy link

As part of my PhD research on code authorship, we calculated the Truck Factor (TF) of some popular GitHub repositories.

As you probably know, the Truck (or Bus) Factor designates the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. In our work, we consider that a system is in trouble if more than 50% of its files become orphan (i.e., without a main author).

More details on our work in this preprint: https://peerj.com/preprints/1233

We calculated the TF for io.js and obtained a value of 5.

The developers responsible for this TF are:

isaacs - author of 23% of the files
Ryan Dahl - author of 22% of the files
Ben Noordhuis - author of 18% of the files
Fedor Indutny - author of 10% of the files
koichik - author of 3% of the files

To validate our results, we would like to ask io.js developers the following three brief questions:

(a) Do you agree that the listed developers are the main developers of io.js?

(b) Do you agree that io.js will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)?

(c) Does io.js have some characteristics that would attenuate the loss of the listed developers (e.g., detailed documentation)?

Thanks in advance for your collaboration,

Guilherme Avelino
PhD Student
Applied Software Engineering Group (ASERG)
UFMG, Brazil
http://aserg.labsoft.dcc.ufmg.br/

@Fishrock123 Fishrock123 added the question Issues that look for answers. label Aug 10, 2015
@rvagg
Copy link
Member

rvagg commented Aug 10, 2015

Sorry @gavelino, this is not the place for this and your information is far from current. Please leave an email address here if you'd like someone to take it further, then if anyone has the time and energy to do so they can follow it up with you directly.

@rvagg rvagg closed this as completed Aug 10, 2015
@Fishrock123 Fishrock123 added invalid Issues and PRs that are invalid. and removed question Issues that look for answers. labels Aug 10, 2015
@Fishrock123
Copy link
Contributor

Do you agree that io.js will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)?

...

isaacs - author of 23% of the files
Ryan Dahl - author of 22% of the files

Both of these people have already effectively left. :P

@mikeal
Copy link
Contributor

mikeal commented Aug 10, 2015

The metrics you're using seem to be based on looking at the total number of changes committed by a person to a file. This is a pretty poor metric to use for the questions you've asked because they don't seem to take in to account how recent the activity is by the people you've noted as being the maintainer compared to other contributors.

As we've noted, two of the 5 people in your list has already left and yet the project as a whole has more contributors, and contributions, than ever before so it may be prudent to re-calibrate how you're arriving at these metrics before asking too many projects about their efficacy.

A much better metric to consider would be what percentage of the changes to these files a single person has made and if any files have not been touched by anyone else on some kind of time scale. Or even to consider the percentage of files that have only been touched by a single person.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid Issues and PRs that are invalid.
Projects
None yet
Development

No branches or pull requests

4 participants