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

Mon Sep 22 15:57:40 UTC 2014

On Sun, Sep 21, 2014 at 7:20 PM, Randall Leeds <randall at bleeds.info> wrote:

> 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.)
>

+1 for making that clear to the "by standards" (like myself). :)

> > 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.
>

This may not come as a shock, but lots of communities are (and likely have)
been dealing with this same issue. Here's a thread I was recently apart of
(on GitHub):
https://github.com/jgm/stmd/issues/126

I ended up in that thread because of being told I was in the wrong place
and needed to repost. :-(
https://github.com/jgm/stmd/issues/121

The frowny face is because it shut down my (current) interest and activity
with that project--as I have no (current) desire to sign-up for another
account on another site to post the same message to the same people.

tl;dr It's your project. You curate it. I'm just here to help.

It maps to the Principle of Least Effort:
http://en.wikipedia.org/wiki/Principle_of_least_effort

In this case (again, currently) the bar was too high for my time / interest
/ attention, so it shut down my participation.

I'd have preferred it (and offered as much) that they re-post on my behalf
to wherever they want to keep stuff, and link it from the place I'd
originally put it. Like it's a Web or something. :-P

While AnnotatorJS (and any other project) should have it's preferred mode,
storage locations, etc, *none* of that should inhibit someone's interaction
with the project.

Committers / team-members / whoever, should feel free to curate how they
like, and route people with URL's and links as needed!

The tricky bit is dealing with all the self-inflicted walled gardens, but
that shouldn't be your brand-new-community-participants problem.

Help them help. :)

> 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.
>

On the email front, Randall's spot on. Few things beat email when it comes
to the range of tooling for managing one's own chaos. :)

Perhaps the help to the "self-inflicted walled gardens" problem (for now)
is to use something like Zapier.com to at least make the Mailing List
(presumably having a wider audience than GH) aware of activity on GitHub by
have Zapier send emails on New Issues (at least).

The wall is still there for interaction, and it's quite possible there'd be
2 conversations going on, but at least one group wouldn't be "lesser" than
the other.

That said, all of this is "self-inflicted" pain (perhaps unavoidably so at
the moment), and causing it to new comers is the real danger.

Anyway.... :)

To quote Randall from earlier:
"...there [is] no hostility or real divergence...just discussing
contribution processes on GitHub, and triage etiquette."

Every open source community is, has, or will be facing this at some point.

It's a nice problem to have, actually. :)

Thanks for listening,
Fairly-new-comer Benjamin ;)

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!
>
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140922/a7575e01/attachment-0004.html>