[yt-dev] let's talk about Governance

[Brian O'Shea]

Hi Britton,

No worries - I also don't quite know what a community representative's role
would look like either, and it may simply be that it's something that the
meeting organizer needs to be sure to bring up a lot.

After thinking about it a bit, I realized that ultimately my concern is
that the people involved in the team meetings are (essentially by
definition) going to be the most active yt developers, and thus those yt
*users* that are most comfortable with large and/or frequent changes to yt
and its interface, due to their nature and also to the fact that they're
paying close attention to the development process.  This comfort level
means that significant changes don't feel like as big of a deal to them,
and thus they're more likely to sign off on them (which is not necessarily
a bad thing). Users that are more removed from the development process and
less comfortable with code and code development (undergrad research
students, for example) have a much more challenging time dealing with these
major changes (the yt 2.x->3.x transition), and a great deal of
productivity is lost that could probably be avoided.

By the way, I realize that sounds like a condemnation of the yt development
process, and I assure you that I don't intend it to be. Given how much the
user base of yt has grown, and how much its functionality, portability, and
scalability has increased over the last handful of years, some growing
pains are inevitable.  As the code continues to mature and the user
community grows, there will be a larger proportion of computationally
less-sophisticated users, though - so let's be as kind to them as possible!

Brian



On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith <brittonsmith at gmail.com>
wrote:

> HI Brian,
>
> I couldn't agree more on having a documentation representative present at
> team meetings.  In fact, I think this was even in my original draft, but I
> somehow lost track of it.  Thanks for bringing it up.  I will get that back
> in there.  A community representative is also a good idea, but I'm less
> sure how that role would be filled.  If anyone has any thoughts on that,
> please do share.  If it can't be figured out before the YTEP is accepted,
> we can definitely amend it.  Thanks, Brian!
>
> Britton
>
>
> On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>
>> Hi Brian,
>>
>> On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea <bwoshea at gmail.com> wrote:
>> > Hi folks,
>> >
>> > Chiming in as somebody who is on the far periphery of yt development
>> (having
>> > only contributed a couple of bug fixes/minor updates), I think that
>> creation
>> > of a formal governance structure is a significant positive step.  Given
>> the
>> > distributed nature of the development team some level of coordination is
>> > critical, and I also think that having a set of carefully-considered
>> > standards about who gets a vote in terms of code direction, and how
>> many of
>> > these votes are needed to enact substantial change (as opposed to the
>> ad-hoc
>> > "preponderance of +1s from the mailing list" method) is an exceedingly
>> good
>> > idea, as it will hopefully enhance the group's decision-making and make
>> it
>> > more reflective.
>> >
>> > I also want to comment on the monthly team meetings.  In addition to
>> posting
>> > meeting minutes, perhaps the meeting coordinator or secretary could
>> organize
>> > an agenda for the meeting and post it to the yt-dev mailing list a
>> couple of
>> > days ahead of time?  That way, people who are not participating in the
>> > meeting, but who may have some input on the issues at hand, have an
>> > opportunity to email suggestions.
>> >
>> > Finally, one other point: I can't help but notice that while the
>> technical
>> > aspects of yt will be represented in these team meetings, there is no
>> > *explicit* representation of the yt user community or yt documentation.
>> > While in principle this isn't a problem -- Matt has made the point many
>> > times that the difference between user and developer isn't necessarily
>> > meaningful in our context -- I do think that having somebody involved
>> whose
>> > explicit responsibility is to consider the questions "how will this
>> impact
>> > the broader yt user community?" and "what's missing from the
>> documentation
>> > that could be added or improved?" may be beneficial.
>>
>> Yes, I agree.  I actually have a few people I would submit as
>> nominations for this role, but it seems to me it's certainly one that
>> should be represented.
>>
>> >
>> > Anyway, small nit-picks aside, I think this is a great idea.  Thanks to
>> > Britton for starting the ball rolling!
>> >
>> > --Brian
>> >
>> >
>> >
>> >
>> > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>> >>
>> >> Hi Britton,
>> >>
>> >> I think this is really, really important, and I'm really happy with
>> >> the YTEP as it stands.
>> >>
>> >> We've only gotten feedback from a few people.  I think it's really
>> >> important to get both positive and negative feedback from people on
>> >> this -- even to the level of "geez, stop taking yourselves so
>> >> seriously!" :)  Do you think maybe an email to the yt-users mailing
>> >> list would be productive?  Or even directly writing to the people
>> >> identified as "founding" members?
>> >>
>> >> -Matt
>> >>
>> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith <brittonsmith at gmail.com
>> >
>> >> wrote:
>> >> > Hi everyone,
>> >> >
>> >> > I have just issued a pull request to the YTEP repository containing
>> an
>> >> > initial draft of yt team guidelines.  I encourage everyone to take a
>> >> > look at
>> >> > it and offer their feedback.  In case you don't get the notification,
>> >> > the PR
>> >> > can be viewed here:
>> >> >
>> >> >
>> https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infrastructure/diff
>> >> >
>> >> > Britton
>> >> >
>> >> >
>> >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith <
>> brittonsmith at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Sam,
>> >> >>
>> >> >> This is an excellent point.  I think it's important not to
>> overburden a
>> >> >> single person by being forever responsible for a large chunk of the
>> >> >> code.  I
>> >> >> also think it's good to give as many as are willing an opportunity
>> to
>> >> >> share
>> >> >> the role.  Perhaps there is a team of people or subcommittee that is
>> >> >> responsible for figuring out who their representative is.  This can
>> be
>> >> >> ironed out.
>> >> >>
>> >> >> I think we've gotten enough positive response to start thinking
>> about a
>> >> >> YTEP that lays it all out.  I will start something this week, ask
>> for
>> >> >> feedback, and we can all develop this together.
>> >> >>
>> >> >> In the mean time, if you would still like to chime in on this
>> >> >> discussion,
>> >> >> please do so.
>> >> >> Thanks, everyone.
>> >> >>
>> >> >> Britton
>> >> >>
>> >> >>
>> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman <
>> samskillman at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi all,
>> >> >>>
>> >> >>> Britton -- I really like these ideas, and I like the member level
>> >> >>> being
>> >> >>> defined as write access.
>> >> >>>
>> >> >>> I'm a bit more concerned about the officers designation in terms of
>> >> >>> the
>> >> >>> logistics of matching people with sections of the code. I could see
>> >> >>> something working where on a 6-month basis, each of the main areas
>> in
>> >> >>> yt are
>> >> >>> assigned a lead.  That lead isn't necessarily the person who has
>> >> >>> written the
>> >> >>> most in the area, but rather a person who is willing to keep track
>> of
>> >> >>> that
>> >> >>> area of the codebase for the next 6 months, so that when it comes
>> to
>> >> >>> doing
>> >> >>> releases, they are the ones that know what has changed and where
>> >> >>> things are
>> >> >>> not working well.  Maybe that's too much of a process, but I also
>> >> >>> think we
>> >> >>> should be wary of assigning potentially long-lasting labels to
>> either
>> >> >>> people
>> >> >>> or code. Semi-regular meetings for this set of people would be
>> great.
>> >> >>>
>> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look
>> >> >>> forward
>> >> >>> to hearing more!
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Sam
>> >> >>>
>> >> >>>
>> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller <kellerbw at mcmaster.ca
>> >
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> +1, absolutely.  Right now, yt has a really high bus factor.  I
>> think
>> >> >>>> this would help that a lot.
>> >> >>>>
>> >> >>>>
>> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
>> >> >>>> <chris.m.malone at gmail.com>
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> +1 as well on all suggestions
>> >> >>>>>
>> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki <karraki at nmsu.edu>
>> >> >>>>> > wrote:
>> >> >>>>> >
>> >> >>>>> > I wanted to put my strong +1 out there even though I don't
>> respond
>> >> >>>>> > often to dev emails. This sounds like a great direction for yt!
>> >> >>>>> >
>> >> >>>>> > -Kenza
>> >> >>>>> >
>> >> >>>>> > ---
>> >> >>>>> > Kenza Arraki
>> >> >>>>> > PhD candidate
>> >> >>>>> > New Mexico State University
>> >> >>>>> > Department of Astronomy
>> >> >>>>> >
>> >> >>>>> >
>> >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
>> >> >>>>> > <michael.zingale at stonybrook.edu> wrote:
>> >> >>>>> >> these all sound like good ideas to me.  Some simply operating
>> >> >>>>> >> procedures,
>> >> >>>>> >> like "don't merge your own pull requests" might be good too.
>> >> >>>>> >>
>> >> >>>>> >>
>> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
>> >> >>>>> >> <brittonsmith at gmail.com>
>> >> >>>>> >> wrote:
>> >> >>>>> >>>
>> >> >>>>> >>> I'm very in favor of putting some official procedures into a
>> >> >>>>> >>> YTEP.
>> >> >>>>> >>> Having
>> >> >>>>> >>> a codified process may also help with conflict resolution as
>> >> >>>>> >>> well.
>> >> >>>>> >>>
>> >> >>>>> >>> Apache does something with their projects where developers
>> who
>> >> >>>>> >>> make
>> >> >>>>> >>> sustained contribution are made "members" after nomination by
>> >> >>>>> >>> another member
>> >> >>>>> >>> and are given write access to the main repo.  It's a small
>> >> >>>>> >>> thing,
>> >> >>>>> >>> but if we
>> >> >>>>> >>> perhaps have an official definition of "yt member" in a YTEP
>> >> >>>>> >>> with a
>> >> >>>>> >>> posted
>> >> >>>>> >>> list of members, it can be something people can point to as a
>> >> >>>>> >>> way
>> >> >>>>> >>> of
>> >> >>>>> >>> demonstrating that they've done significant work on the
>> project.
>> >> >>>>> >>>
>> >> >>>>> >>> I think it might also be good to have officer-like positions
>> >> >>>>> >>> where
>> >> >>>>> >>> people
>> >> >>>>> >>> are representatives for various areas of the code, such as
>> data
>> >> >>>>> >>> structures,
>> >> >>>>> >>> visualization, analysis_modules, etc. and to have
>> semi-regular
>> >> >>>>> >>> meeting of
>> >> >>>>> >>> these people.  This may be as much leadership as we need for
>> >> >>>>> >>> now,
>> >> >>>>> >>> just a
>> >> >>>>> >>> group that meets on a schedule to make sure everyone's on the
>> >> >>>>> >>> same
>> >> >>>>> >>> page with
>> >> >>>>> >>> releases and major development efforts.
>> >> >>>>> >>>
>> >> >>>>> >>> What do people think of something like this?
>> >> >>>>> >>>
>> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
>> >> >>>>> >>> <matthewturk at gmail.com>
>> >> >>>>> >>> wrote:
>> >> >>>>> >>>>
>> >> >>>>> >>>> Hi Britton,
>> >> >>>>> >>>>
>> >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also
>> I
>> >> >>>>> >>>> think
>> >> >>>>> >>>> really important.  At the WSSSPE conference last year, a
>> paper
>> >> >>>>> >>>> was
>> >> >>>>> >>>> submitted talking about the Apache model:
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Through_Open_Governance/790761
>> >> >>>>> >>>>
>> >> >>>>> >>>> which talks about a lot of related topics.  Apache does some
>> >> >>>>> >>>> interesting things.  They use the word "meritocracy" which
>> I am
>> >> >>>>> >>>> rather
>> >> >>>>> >>>> -1 on using (see, for instance,
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> >> >>>>> >>>>
>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community
>> >> >>>>> >>>> ) but I do think there is something to be said for a large
>> part
>> >> >>>>> >>>> of
>> >> >>>>> >>>> their methods of organization.
>> >> >>>>> >>>>
>> >> >>>>> >>>> Like you, I think we are overdue.  I would like to point out
>> >> >>>>> >>>> that,
>> >> >>>>> >>>> for
>> >> >>>>> >>>> all intents and purposes, you are *already* the ombudsman
>> for
>> >> >>>>> >>>> the
>> >> >>>>> >>>> yt
>> >> >>>>> >>>> community.  I don't think you're proposing we have a
>> committee
>> >> >>>>> >>>> that
>> >> >>>>> >>>> bosses everyone around, but rather one that enables a larger
>> >> >>>>> >>>> number of
>> >> >>>>> >>>> people to have a say, particularly because yt has become
>> >> >>>>> >>>> embedded
>> >> >>>>> >>>> in
>> >> >>>>> >>>> many of our scientific workflows and it touches a lot of
>> >> >>>>> >>>> research
>> >> >>>>> >>>> activities now.  I like the idea of members.  I like the
>> idea
>> >> >>>>> >>>> of a
>> >> >>>>> >>>> project management committee, but it's not clear to me how
>> that
>> >> >>>>> >>>> would
>> >> >>>>> >>>> work, or which decisions we have made recently that they
>> would
>> >> >>>>> >>>> weigh
>> >> >>>>> >>>> in on.  I also really like the idea of having "code
>> liasons" to
>> >> >>>>> >>>> different data platforms and/or communities, and the idea of
>> >> >>>>> >>>> having
>> >> >>>>> >>>> people who are responsible for many different areas of the
>> code
>> >> >>>>> >>>> and
>> >> >>>>> >>>> codifying that in some way is quite attractive to me.
>> >> >>>>> >>>>
>> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a presentation
>> on
>> >> >>>>> >>>> my
>> >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA).  The
>> >> >>>>> >>>> thing
>> >> >>>>> >>>> is,
>> >> >>>>> >>>> while I gave this presentation, it's just *my* vision -- it
>> is
>> >> >>>>> >>>> not
>> >> >>>>> >>>> necessarily anyone else's vision.  And I think it's time we
>> >> >>>>> >>>> have
>> >> >>>>> >>>> some
>> >> >>>>> >>>> method of taking into account a diverse set of opinions for
>> >> >>>>> >>>> what
>> >> >>>>> >>>> we as
>> >> >>>>> >>>> a community can emphasize, how we resolve conflicts, and so
>> on
>> >> >>>>> >>>> and
>> >> >>>>> >>>> so
>> >> >>>>> >>>> forth.
>> >> >>>>> >>>>
>> >> >>>>> >>>> Again, thanks for bringing this up.  We need to have this
>> >> >>>>> >>>> conversation.
>> >> >>>>> >>>>
>> >> >>>>> >>>> -Matt
>> >> >>>>> >>>>
>> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
>> >> >>>>> >>>> <brittonsmith at gmail.com>
>> >> >>>>> >>>> wrote:
>> >> >>>>> >>>>> Greeting yt developers,
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> First, I want to congratulate everyone here on the
>> successful
>> >> >>>>> >>>>> release
>> >> >>>>> >>>>> of yt-3.0.  This was a massive effort on the part of so
>> many
>> >> >>>>> >>>>> and
>> >> >>>>> >>>>> a
>> >> >>>>> >>>>> true testament to the strength of this team.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> At the time of writing this, there are 78 members of the
>> >> >>>>> >>>>> yt-dev
>> >> >>>>> >>>>> mailing list.  As someone who does most of their work in
>> very
>> >> >>>>> >>>>> small
>> >> >>>>> >>>>> collaborations, this amazes me and make me very proud.  In
>> >> >>>>> >>>>> case
>> >> >>>>> >>>>> you're
>> >> >>>>> >>>>> wondering, the yt-users list has 268 members.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> As a project, yt has a significant amount of
>> infrastructure:
>> >> >>>>> >>>>> code
>> >> >>>>> >>>>> review with pull requests, issue tracking, automated
>> testing,
>> >> >>>>> >>>>> emails
>> >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops.
>> All
>> >> >>>>> >>>>> of
>> >> >>>>> >>>>> this
>> >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing.  However,
>> one
>> >> >>>>> >>>>> big
>> >> >>>>> >>>>> missing piece is a system of governance.  I don't know
>> exactly
>> >> >>>>> >>>>> what
>> >> >>>>> >>>>> this means, but I have some ideas, which I will share
>> below.
>> >> >>>>> >>>>> What I
>> >> >>>>> >>>>> want to do right now is to start a discussion that will,
>> >> >>>>> >>>>> hopefully,
>> >> >>>>> >>>>> include as many people as possible on this list.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> For me, governance means (roughly) the following:
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - a set of procedures in writing for how various things
>> are to
>> >> >>>>> >>>>> be
>> >> >>>>> >>>>>  done, such as acceptance of pull requests, releases,
>> >> >>>>> >>>>> designating
>> >> >>>>> >>>>>  developers as core contributors, etc.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - a governing body to make decisions and help guide the
>> >> >>>>> >>>>> project.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> This accomplishes a number of things, which as a project I
>> >> >>>>> >>>>> think
>> >> >>>>> >>>>> we
>> >> >>>>> >>>>> need, such as:
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - overall stability of the project.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - providing a system for conflict resolution.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> - providing a way for active contributors to get credit for
>> >> >>>>> >>>>> their
>> >> >>>>> >>>>>  contribution in the form of official recognition.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> So, these are my initial thoughts, but I really think this
>> >> >>>>> >>>>> deserves a
>> >> >>>>> >>>>> thorough discussion with as many people participating as
>> >> >>>>> >>>>> possible.
>> >> >>>>> >>>>> Please, think about what governance means to you, whether
>> we
>> >> >>>>> >>>>> need
>> >> >>>>> >>>>> it,
>> >> >>>>> >>>>> what it should be, and what we might get out of it, and
>> share
>> >> >>>>> >>>>> your
>> >> >>>>> >>>>> thoughts over the next few days.  I look forward to this
>> >> >>>>> >>>>> discussion.
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> Britton
>> >> >>>>> >>>>>
>> >> >>>>> >>>>>
>> >> >>>>> >>>>> _______________________________________________
>> >> >>>>> >>>>> yt-dev mailing list
>> >> >>>>> >>>>> yt-dev at lists.spacepope.org
>> >> >>>>> >>>>>
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>> >>>> _______________________________________________
>> >> >>>>> >>>> yt-dev mailing list
>> >> >>>>> >>>> yt-dev at lists.spacepope.org
>> >> >>>>> >>>>
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>> >>>
>> >> >>>>> >>>
>> >> >>>>> >>>
>> >> >>>>> >>> _______________________________________________
>> >> >>>>> >>> yt-dev mailing list
>> >> >>>>> >>> yt-dev at lists.spacepope.org
>> >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>> >>
>> >> >>>>> >>
>> >> >>>>> >>
>> >> >>>>> >> --
>> >> >>>>> >> Michael Zingale
>> >> >>>>> >> Associate Professor
>> >> >>>>> >>
>> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony
>> >> >>>>> >> Brook,
>> >> >>>>> >> NY
>> >> >>>>> >> 11794-3800
>> >> >>>>> >> phone:  631-632-8225
>> >> >>>>> >> e-mail: Michael.Zingale at stonybrook.edu
>> >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale
>> >> >>>>> >>
>> >> >>>>> >> _______________________________________________
>> >> >>>>> >> yt-dev mailing list
>> >> >>>>> >> yt-dev at lists.spacepope.org
>> >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>> > _______________________________________________
>> >> >>>>> > yt-dev mailing list
>> >> >>>>> > yt-dev at lists.spacepope.org
>> >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>> _______________________________________________
>> >> >>>>> yt-dev mailing list
>> >> >>>>> yt-dev at lists.spacepope.org
>> >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> yt-dev mailing list
>> >> >>>> yt-dev at lists.spacepope.org
>> >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> yt-dev mailing list
>> >> >>> yt-dev at lists.spacepope.org
>> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > yt-dev mailing list
>> >> > yt-dev at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140830/48fc91c7/attachment.html>