Guiding principle for managing Vimium's Github issues

[Phil Crosby]

Hey everyone,

I'd like to solicit ideas for cleaning up Vimium's Github issue tracker. There are 119 open issues and it's hard to sift through.

https://github.com/philc/vimium/issues

There are at least four types of issues which are all merged together into one issues list:

1. Bugs which we really should look at soon

2. Bugs which affect a niche use case which we probably will never have the resources to fix

3. Features which are tractable in the coming weeks or months

4. "Someday/maybe" features

At my company, we've seen great gains in focus and happiness by removing everything from view (from the list of issues) which isn't actionable soon. I'd like to get the same productivity gains in Vimium.

A few ideas:

a) close issues which we don't intend to act on soon

b) leave them open but make more structured & consistent use of Github's labels

c) move some things (particularly #4) to wiki pages

What do you think?

-Phil Crosby

[Ilya Sukhar]

My ordering of the options is probably (b), (a), (c). I prefer not to have to manually move things from issues to the wiki.

Ilya

[Jez]

Yeah, I think b) makes the most sense. #1 could go under 'todo', #2 could go under 'wishlist' and / or 'helpwanted', and #4 could go under 'explore'. I wonder if milestones would help us here; I've never used them before. We might also want to document wontfixes in the wiki.

Aside from that, I don't have a preference between a) and c).

Jez

[Jez]

Following up on this. It seems that we're still using a), and I would really prefer b) -- I think it's not very nice to put in effort into writing an issue or even a PR and get it summarily closed. This is a recent example. I would prefer it if we could at least leave the PR open for 1-2 months so interested users can discover it, try it out, and possibly comment on it.

Jez

[Phil Crosby]

A baking period for new pull requests might be worthwhile, but I also don't want to leave people's PR's dangling if we have no intention of merging them. As you suggested, let's use this policy for pull requests:

we comment right away as to whether we think we'll eventually merge it, and even if not, we'll leave it open a couple of months for folks to try it before we close it.

For issues, let's try using labels. The balance is that the issues which have been categorized but become irrelevant over time don't remain open, cluttering the issue tracker. If the situation is worse in 6 months with heavy usage of labels I'll revive this thread.

Regarding the specific PR you referenced (#634), that was an implementation with no discussion on the issue tracker and which we had considered a year ago and declined, so I don't think leaving it open would benefit anyone.

[Jez]

On Mon, Sep 3, 2012 at 2:23 AM, Phil Crosby <phil....@gmail.com> wrote: 

A baking period for new pull requests might be worthwhile, but I also don't want to leave people's PR's dangling if we have no intention of merging them. As you suggested, let's use this policy for pull requests:
we comment right away as to whether we think we'll eventually merge it, and even if not, we'll leave it open a couple of months for folks to try it before we close it.
For issues, let's try using labels. The balance is that the issues which have been categorized but become irrelevant over time don't remain open, cluttering the issue tracker. If the situation is worse in 6 months with heavy usage of labels I'll revive this thread.

Sounds good.

Regarding the specific PR you referenced (#634), that was an implementation with no discussion on the issue tracker and which we had considered a year ago and declined, so I don't think leaving it open would benefit anyone.

Ah, I wasn't aware / had forgotten that we'd considered something like #634 before. Seems reasonable to close it then, but it might be nicer to mention to the author that we've actually thought about it before.

Jez