[annotator-dev] [annotator] Anchor annotations to the closest ancestor ID? (#394)

[Randall Leeds]

On Sep 21, 2014 2:54 PM, "leinfelder" <notifications at github.com> wrote:
>
> Certainly, feature requests need to be triaged to be useful to anyone -
especially the core team. It seems like having those potential items in a
forum like this is a good way to organize and evaluate them through
discussion and informal voting just like we are doing now. On this topic
alone, there are three different people clamoring for the feature and one
[possibly] threatening to fork and never look back; not the kind of new
projects we want to be encouraging...
>

(For anyone just tuning in, there was no hostility or real divergence,
we're just discussing contribution processes on GitHub, and triage
etiquette.)

> It seems like you do your project planning and outreach on github, so I'm
not sure why you wouldn't want all the information to do that planning in
that same location. There are already "question", "enhancement" and
"Backlog" labels as well as a "v2.0" milestone. Why not use them to your
benefit? Questions become a ready-made FAQ section and reduce traffic on
your email list over time, while enhancements allow you to do informed
project planning in a transparent way. Collaboration Shangri-La!
>

I'm hearing you.

I'll cross post this to the mailing list, because even as we talk about it
I'm concerned that we're excluding precisely the audience that would
potentially object :-D.

I don't have a sense of whether there's a big constituency that agrees, but
I consider email the most accessible collaboration medium for a diverse
audience of maintainers, developers, and users.

For all that is great about GitHub, folks have at their disposal a
diversity of tools and practices for sorting, organizing, prioritizing,
drafting, and conversing via email.

I don't have any problem with enhancements having GitHub tickets, but I do
think it's important to have an active mailing list and that it is the best
place to  establish fitness for inclusion and community interest when
discussing proposed changes and features ahead of implementation.

:-/

As Nick said, reopen anything that gets closed if you want to look at it
again. I don't think that's mutually exclusive of encouraging use of the
mailing list.

If you find email useful or you think it fragments and or hides things
you'd rather have on GitHub, speak up, whatever your thoughts! I am
perennially somewhat enamored with this conversation (really!) each time it
comes up somewhere I subscribe.

I think my preference is to take your thoughts about FAQ, roadmap, etc, and
to turn that into better documentation that is in the repo, which would
provide that transparency of purpose and scope to reduce bewilderment, but
for active discussion of proposals pre-implementation we simply document
and encourage email as preferred first contact.

Reasonable? Dumb and backward? Heh. I don't know!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140921/efabb3c0/attachment-0003.html>