[Yt-dev] Parallelism, or, how I learned to stop worrying and love open source development

[j s oishi]

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.