[annotator-dev] Issue purge

[Nick Stenning]

On Sun, Sep 21, 2014, at 21:44, Ben Leinfelder wrote:
> Hi Nick,
>
> As a very new member of this community, I found it extremely useful to
> browse the list of "issues" in this centralized github location. I
> started to comb through the email list archives, but that was rather
> tedious and getting the full context of any particular topic was, well,
> difficult (and maybe I missed it, but it was also not searchable).

So, to address Ben's concerns (and I get the impression they're shared
by others), I want to clarify a few things.

1. Roadmaps are an important part of a project's documentation.

People want to know what's coming in future versions of Annotator, and
having a place to record that is helpful. By pruning non-defect-related
issues out of GitHub, I'm not suggesting that we won't have such a
place, merely that it won't be GitHub. As such, I intend to start
working on a roadmap document that can form part of Annotator's
documentation. Discussions on the mailing list can filter into this
document as appropriate.

2. Pull requests for new features are *always welcome*

While GitHub is no longer the place for feature requests, it is still
obviously OK to send us a pull request with your desired feature
implemented (and tested, and documented!). The maintainers will happily
provide code reviews and advice on pull requests. However, it is
important to stress that if you're embarking on a new piece of work,
it's probably still worth raising it on the mailing list, both to ensure
that you're not duplicating effort, and because you may get useful
advice on how and where to implement your feature.

3. In general, we are aware that we need *more* community-supporting
documentation and process, not less

Annotator's documentation is, to put it simply, dire. We know that we
have a long way to go here, and over the coming weeks and months I'm
hoping we can address these issues (with your help!). Purging of
non-actionable or vague issues is purely a way of helping maintainers
identify what needs doing when, rather than allowing the GitHub issues
list to act as a monotonically increasing work pile!

---

Lastly, to stress again -- if you think I've closed an issue that
shouldn't be closed, don't take it the wrong way, just reopen it and
explain why it needs to be on our radar.

All the best,
Nick