4 ms·

It's a shame GitHub puts effort into stuff like this as opposed to actually listening to their users (e.g. "Dear GitHub"). We can infer a shift from GitHub to

It's a shame GitHub puts effort into stuff like this as opposed to actually listening to their users (e.g. "Dear GitHub"). We can infer a shift from GitHub to alternate services soon from this, unless they change.

skewart 11y ago
To be fair, developing something like this is probably orthogonal to developing the kinds features they have been neglecting to develop recently. Scientist was probably entirely within engineering, and not a massive effort. Making the things users are asking for would be a much bigger effort across the organization. But, I do completely agree that they've been dropping the ball lately.
jowiar 11y ago
This is Github open-sourcing an internal tool, which is something they have a long history of doing (Jekyll, Resque, Hubot). Most dev shops have a whole bunch of things like this -- assorted libraries and internal tools that are 80-90% of the way to being somewhat useful to the public. It's fantastic that Github provides the time/space/expectation for employees to finish them.
riyadparvez 11y ago
I don't see how this is relevant. Do you want to see Github implement your favorite feature, but at the same time the bugs introduced in the new version breaks the existing functionalities? That's what this library does. It ensures new bugs do not take down existing functionalities. Multi-version execution is an active area of research [1]. [1]: http://srg.doc.ic.ac.uk/files/papers/mx-icse-13.pdf http://srg.doc.ic.ac.uk/files/papers/mx-icse-13.pdf
gedrap 11y ago
I remember seeing this project more than a year ago (I believe it was call dat_science back then). >> We can infer a shift from GitHub to alternate services soon from this, unless they change. Nope. People are lazy. Will a lot of people write comments and all, how they are going to totally move away from github? Oh yeah, no doubt. But will they actually do it? Nah, just a few, unless github becomes as bad as source forge but I don't think it's going to happen, even then it would take some time. Yes, yes, I am aware that migrating is just a matter of adding a new origin. That's the easy bit. But getting used to a new interface and everything, that takes much more effort and time. Writing a comment is easier (especially when tons of people are doing that around you) than changing your habits. Even ignoring everything above, I don't really agree with the "puts effort into stuff like this as opposed to actually listening to their users" attitude. GitHub is not a one man's project. The whole company shouldn't drop everything just to do something right now because it was trending on HN a week or two ago. A company like this (making substantial product changes rather urgently based on some hype) maybe sounds cool but, in reality, you would probably not be excited to use their products. Urgent changes in features and quality often does not go together.

skewart 11y ago

To be fair, developing something like this is probably orthogonal to developing the kinds features they have been neglecting to develop recently. Scientist was probably entirely within engineering, and not a massive effort. Making the things users are asking for would be a much bigger effort across the organization. But, I do completely agree that they've been dropping the ball lately.

jowiar 11y ago

This is Github open-sourcing an internal tool, which is something they have a long history of doing (Jekyll, Resque, Hubot). Most dev shops have a whole bunch of things like this -- assorted libraries and internal tools that are 80-90% of the way to being somewhat useful to the public. It's fantastic that Github provides the time/space/expectation for employees to finish them.

riyadparvez 11y ago

I don't see how this is relevant. Do you want to see Github implement your favorite feature, but at the same time the bugs introduced in the new version breaks the existing functionalities? That's what this library does. It ensures new bugs do not take down existing functionalities. Multi-version execution is an active area of research [1]. [1]: http://srg.doc.ic.ac.uk/files/papers/mx-icse-13.pdf http://srg.doc.ic.ac.uk/files/papers/mx-icse-13.pdf

gedrap 11y ago

I remember seeing this project more than a year ago (I believe it was call dat_science back then). >> We can infer a shift from GitHub to alternate services soon from this, unless they change. Nope. People are lazy. Will a lot of people write comments and all, how they are going to totally move away from github? Oh yeah, no doubt. But will they actually do it? Nah, just a few, unless github becomes as bad as source forge but I don't think it's going to happen, even then it would take some time. Yes, yes, I am aware that migrating is just a matter of adding a new origin. That's the easy bit. But getting used to a new interface and everything, that takes much more effort and time. Writing a comment is easier (especially when tons of people are doing that around you) than changing your habits. Even ignoring everything above, I don't really agree with the "puts effort into stuff like this as opposed to actually listening to their users" attitude. GitHub is not a one man's project. The whole company shouldn't drop everything just to do something right now because it was trending on HN a week or two ago. A company like this (making substantial product changes rather urgently based on some hype) maybe sounds cool but, in reality, you would probably not be excited to use their products. Urgent changes in features and quality often does not go together.