We've got issues
Our implementation of Button Men isn't perfect. Nor is it complete.
In fact, at the time of writing this blog post, we have 396 open issues worth of imperfection and incompleteness. However, we also have 775 closed issues worth of completeness.
If you haven't yet taken a look at our issue tracker on Github, you might find it interesting to have a browse.
I find that browsing issues in chronological order helps me to keep my perspective on what we've already achieved. For example, our oldest open issue has an issue number of 108, and there are only 10 issues still open with an issue number less than 200.
Of course, this is slightly confounded by the fact that pull requests (which contain submitted bits of code) use the same numbering system as issues, and that pull requests make up roughly half of the total number of issues. But even so, that means that we have addressed roughly 90% of the issues from the first 100 real (non-pull-request) issues.
Since we have 396 open issues and 775 closed issues, we've been able to deal with roughly two-thirds of all issues since we began issue tracking.
Each deployment, we tend to address somewhere between 1 and 10 issues, although not every issue is fully resolved each time it is addressed. We normally like to address one big issue, one or two small issues, and a couple of trivial issues, because that means that we can work on multiple issues simultaneously, without having to worry about code conflicts or complicated code merges.
At this rate, we'll never run out of issues. However, that's not a bad thing, I think. Having a pool of issues means that we can always have something to work on in which we are personally interested, while still being useful for many users on the site. It means that occasional devs with only a small amount of time to contribute can work on small issues, while devs with more time can tackle something with more substance. It means that if we get stuck on a difficult issue, we can leave it and move on to something else that is more tractable.
However, having a large pool of issues also means that we sometimes forget about issues. And sometimes, we need our users to remind us that an issue is there, and that they're being affected adversely because the issues hasn't been addressed. So, if you've found something rather annoying about the site and you don't see us working on it, perhaps we've just forgotten. Or perhaps it's too difficult. Or perhaps we just haven't gotten around to it yet. Whatever the reason, we're always more than happy to receive a gentle reminder of the existence of an issue.
And if you happen to implement the solution, we'll be happy enough to work on incorporating it ...
In fact, at the time of writing this blog post, we have 396 open issues worth of imperfection and incompleteness. However, we also have 775 closed issues worth of completeness.
If you haven't yet taken a look at our issue tracker on Github, you might find it interesting to have a browse.
I find that browsing issues in chronological order helps me to keep my perspective on what we've already achieved. For example, our oldest open issue has an issue number of 108, and there are only 10 issues still open with an issue number less than 200.
Of course, this is slightly confounded by the fact that pull requests (which contain submitted bits of code) use the same numbering system as issues, and that pull requests make up roughly half of the total number of issues. But even so, that means that we have addressed roughly 90% of the issues from the first 100 real (non-pull-request) issues.
Since we have 396 open issues and 775 closed issues, we've been able to deal with roughly two-thirds of all issues since we began issue tracking.
Each deployment, we tend to address somewhere between 1 and 10 issues, although not every issue is fully resolved each time it is addressed. We normally like to address one big issue, one or two small issues, and a couple of trivial issues, because that means that we can work on multiple issues simultaneously, without having to worry about code conflicts or complicated code merges.
At this rate, we'll never run out of issues. However, that's not a bad thing, I think. Having a pool of issues means that we can always have something to work on in which we are personally interested, while still being useful for many users on the site. It means that occasional devs with only a small amount of time to contribute can work on small issues, while devs with more time can tackle something with more substance. It means that if we get stuck on a difficult issue, we can leave it and move on to something else that is more tractable.
However, having a large pool of issues also means that we sometimes forget about issues. And sometimes, we need our users to remind us that an issue is there, and that they're being affected adversely because the issues hasn't been addressed. So, if you've found something rather annoying about the site and you don't see us working on it, perhaps we've just forgotten. Or perhaps it's too difficult. Or perhaps we just haven't gotten around to it yet. Whatever the reason, we're always more than happy to receive a gentle reminder of the existence of an issue.
And if you happen to implement the solution, we'll be happy enough to work on incorporating it ...
Comments
Post a Comment