[AstroPy] Co-ordinating Python astronomy libraries?

[Marshall Perrin]

On Jul 6, 2010, at 3:01 PM, Joe Harrington wrote:
>  I think we can have a bit more
> practical vision, and at least for our own stuff (loosely defined) we
> should organize around principles that include these:
> 
> - document the whole, but lightly
> - provide a web community site for discussions, examples, reviews of code

More than just documentation, what I would love to see is a set of tutorials or quick-start guides written at a roughly graduate-student level, that show a few examples of how to use all this code for common tasks. Perry and Robert's famous tutorial document (pydatatut.pdf) is an excellent start, but it's several years old now and misses all the new modules.  I know it's a long way off until we have, say, an actual text in data analysis that we can point students to, but I think it's very important to keep new users (and IDL switchers, etc!) in mind when writing docs, not just other python gurus.   

For the web community site, there are already a few potential candidates (astropython.org, astrobetter.com, etc). My experience with these sorts of things in the past is that it takes a critical mass to keep a web community active and engaging. Seems like half the wikis I know get very little usage... So while everyone is thinking about monolithic vs. distributed package organization, it's probably worth considering that same question as applied to web sites too. 

 - Marshall

> - locate and manage it so that it is owned by the community and
>  survives long-term
>  - ensure all jobs doable by at least 3 people
>  - document procedures well
>  - have formalized community governance and leadership
>  - have a solid funding model
> - agree to hang together, even if you don't like something!
> 
> With those (and perhaps other) goals in mind, we should then look at
> decisions like where/how to host it and what kind of wiki to use.
> 
> Also, I keep thinking that this is best solved by joining forces with
> other scientific communities.  The build-and-test part is hard, but
> once implemented, it scales fantastically.  Again, all of SciPy should
> be doing this.  We should at least build so that if others want to
> join, they have a place to fit in.  This will need to be considered
> when doing package naming conventions.  Generic names should be
> avoided so that two can play in the same sandbox.
> 
> Even if we don't do the full thing from the start, we should plan it
> out and build as though that's where we're eventually going.
> 
> AAS splinter meeting, anyone?
> 
> --jh--
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy