Hi All, I have a few brief thoughts to add.
Overall, though, what really needs to happen is some kind of *buy-in* on the part of the user -- which in this case is anyone who has had trouble with yt. I have pulled back from yt-users, and I'm really happy that everyone else has stepped up. But I'm worried that as time goes on, people will pick up knowledge in ways that aren't indexable by search engines and then this knowledge keeps getting re-learned.
I'm 100% in agreement here about increasing reporting of bugs. I myself am quite guilty of not formally reporting bugs. One thing we might do is to attempt to force yt to ask people to report bugs when it crashes. I'm not sure how easy this might be, but I often report bugs when software I use explicitly tells me to. On the other hand, I think we need to make it as easy as possible for people to report bugs. OpenID is a great idea, and would definitely help. I personally recieve a few bug reports from users privately every now and again. These bugs easily fall into two categories: ones I fix right away, and those that fall into pergatory. I would love to simply say "report the bug on trac, please". Of course, I acknowledge my own fault in not doing myself when handed these bugs.
Public reporting of bugs, particularly as it could relate to improvements in documentation, is essential. But this can't happen if it's just driven by one or two people. And if no one else is motivated to encourage this, then perhaps that's just where we'll stay. I can't force buy-in, I can only encourage people to see the benefits to reporting bugs, sharing experiences, and all of that. We need to have people to read and handle bugs, and then people to whom they apply. I really would like for this not always to be me.
This is a great idea. Can we have trac email us our bugs, or let us know when a bug is assigned to us, or when a new bug comes in? This way we, the non-Matt yt developing community, can assign incoming bugs? I apologize if these are simple things that are already well known, but I'd like to make sure we can make it as easy as possible to have the entire yt development team responding to and categorizing bugs in addition to fixing them.
= Building Community =
* We need to articulate the vision for yt, and I'm not sure my vision is the one anyone else has.
I think we need to create a roadmap for future versions of yt. I think we need to think seriously about what needs rewriting in the internals, what features we want to add, and how long we want to allot ourselves to achieve those goals. Furthermore, we need to explicitly and publically commit to doing those things we're interested in. Any unassigned features/rewrites would then be added to a wishlist, which we could advertise to new users as a way to get in the door. One uphill battle is that most users of yt are astronomers, who do not necessarily have much exposure to free software nor do they necessarily have a lot of desire to get really good at software development. This is very sad, of course, because being a bit better at software development is something that would help anyone using any large AMR simulation codebase. I also agree that documentation features should be classified as bugs. Perhaps we should poll yt-users fairly frequently (once or twice a year) in order to solicit documentation bugs/feature requests. thanks, and many thanks to Matt for the amazing amount of work he's put in to yt thus far. J.S.