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

[Ben Leinfelder]

Email is fantastic as an alert mechanism.* As an archive, it only works if I was subscribed when the discussion began or if there is a reliable, easy to use, and easy to point to repository for prior questions and discussions.

Benjamin was able to point us to two relevant conversations in a project I certainly was not part of, or even aware of…because they were recorded in GitHub. I can explore the entire thread, learn the context of the discussion and maybe even the resolution if I choose to watch the topic. That seems really useful to me. 

Maybe the gmane.org route will work for you. Mentioning that archive somewhere obvious would be useful so that new people like me can do their own legwork before bogging down the list with redundant "how do I…?" or "what do you think about…?" questions. But I think I'd feel awkward joining in the conversation if I had to open an entirely new email with, "hey guys, I saw you were talking about this back in May, thought I'd chime in with my thoughts now…"

Thanks,
-ben

*and cat gifs

On Sep 22, 2014, at 8:57 AM, Benjamin Young <bigbluehat at hypothes.is> wrote:

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