What about Issues?
Closed this issue · 14 comments
We spent a lot of time at the beginning of io.js thinking through how to deal with the split in issues between io.js and node.js. What we finally settled on was just starting over from scratch which turned out to be quite a blessing. From that point on we required that any commit messages refer to the full issue and pr including the org/repo name to distinguish between joyent/node and iojs/io.js issues.
We can recreate everything in io.js and node.js repositories except for issues so the decision of how to start that repo really just comes down to issues.
As I see we have 3 options available:
- Start with joyent/node and all the issues there.
- Start with iojs/io.js and all the issues there.
- Start with a fresh repository.
There are far more issues in joyent/node than any other repository. It also has about 3x the watchers and stars. A ton of those issues are severely outdated despite a valiant effort to clean them up.
Since its creation io.js has done a great job of keep issues clean and well tagged with a high response rate. But, if this has taught us anything it's that starting over from scratch can be accomplished with fairly little negative consequences. Resetting and starting from scratch again gives us a great opportunity to reset the context and if we are changing the tag and triage process at all we won't have to go through thousands of prior issues or have a history of issues that clearly operated under a different process.
pinging @chrisdickinson and @Fishrock123 as they've dealt more than anyone with issues.
I was thinking about this too and quickly came to the conclusion that I do not have enough personal experience in this area to offer an intelligent opinion. Let's ping @tjfontaine, @misterdjules and @mdawsonibm for their thoughts also.
I fretted about this a lot when io.js first went public, which was roughly at the same time nodebug.me came out. I worried that a massive amount of value had been poured into the existing issue tracker, and that value would be lost entirely if we started fresh. Years of conversations, decisions, and technical background were woven into and across issues and pull requests, both opened and closed.
However, io.js seems to be doing well without it, and might even be easier to contribute to without the weight of all of that history bearing down on newcomers. I think io.js' success in dealing with its issue tracker proves that a lot of that weight is now of relatively low value compared to the amount of effort it takes to consume and process it.
(It bears mention that community input in the form of new issues and pull requests is high value at the outset, but depreciates rapidly over time. It requires {pro,}active involvement from contributors to capture that value. The amount of cognitive effort it takes to sift through old issues and pull requests goes up with time and distance from the problem, and most old issues that folks truly care about have been re-opened on io.js itself.)
So, that being said: I'd prefer we either retain the io.js repository (adding the node collaborators), or create a new repository and give all existing node and io.js collaborators commit access.
Start with joyent/node and all the issues there.
I really don't this this is preferable to anyone, unless we can mass-close everything that isn't tagged. Too much to reasonably go through.
Start with iojs/io.js and all the issues there.
io.js has a steady ~6 pages of managed issues, virtually all of which are still relevant.
However, moving/renaming the repo could have consequences on links to issues from commits. And, afaik, you cannot specifically move issues.
So, that being said: I'd prefer we either retain the io.js repository (adding the node collaborators), or create a new repository and give all existing node and io.js collaborators commit access.
What @chrisdickinson said.
I split out workflow notes into a separate issue, but would be happy to discuss it here if that's easier.
Since its creation io.js has done a great job of keep issues clean and well tagged with a high response rate.
I would like to state the most important bit of this:
Having more active (even semi-active) people able to manage to issues has been the best boon of the io.js issue tracker. Bots or other fancy measures simply do not compare.
I'm thinking that a 1 time close all with a comment asking that the original re-open if they believe the issues still needs attention might help identify those that people think are still important. Along the lines of "can you please help us out as we transition, we are going to close all untagged issues, please re-open in this new repo if the issue still needs attention" .
I've been thinking about this a lot and I have to say that I think the best approach is to start with a clean slate.
If we auto-close we're going to upset a lot of people and give them the wrong impression. We want to show contributors that we are more diligent about their issues in a merged project, not less.
Starting with a clean slate gives us the opportunity to seed Issues and PR work for the merger while we continue development on io.js and node.js pre-merger. It forces us to continue to engage with both issue repositories until they can be closed. And finally, we'll have a very good sense of how well we've re-engaged the community under a merged project in the foundation as we see the watch/start count evolve.
So what you are suggesting is a new issues repo and keep the existing node.js and io.js ones alive, just closed to new issues ?
@mdawsonibm correct. After the merger is completed either disable new issue in those repos or alter the README and perhaps add an auto-responder pointing to the new repo. The repos would need to stay up though so that the links to old issues are preserved.
That sounds reasonable to me. Any value in posting a message to the existing issues along the lines of "while we still have your issue and will get to it when we can, new ones are being handled here:X. If your issue is urgent you may want to open a new one here:X". Softer than the close but a heads up that if you really want your issue to get attention now, opening in the new repo will ensure that. The downside would be if too many people use that option and its floods the new repo.
@mdawsonibm that sounds like a good idea.
After the merger is completed either disable new issue in those repos
Doesn't the disable issues access entirely?
opening in the new repo will ensure that. The downside would be if too many people use that option and its floods the new repo.
Won't matter if we are managing issues well.
The new repo should be the new repo for core though. having a separate issues repo for core (NG is a slight exception) is just going to be confusing.
Doesn't the disable issues access entirely?
Won't disable issues also remove them from being able to read or comment on old ones?
The new repo should be the new repo for core though.
Yes, thanks for calling this out. I was assuming it implicitly but just realized this was not actually clear.