On Jul 14, 2005, at 7:26, Will Coleda wrote:
MUahahahahaha, my trap has been sprung! Perfect. I've been looking for
you since before we lost Dan. =-)
Had I know this at the conference, I would have had a much longer
conversation with you. =-)
I can't say I've ever made any secret of the fact. :)
http://dev.perl.org/perl6/people.html
I have a .. few.. questions for you. Hopefully none of them are
*overly* snarky. Some progress has been made dealing with issues like
this since I originally started bringing them up, but I think there's
still room for improvement.
- Where is parrot's current project plan?
- Does it have any more details than the high level grant plan that
was used to fund leo?
Yes and no. We have a good bit more detail, but not all of it is
written down. The first milestone of the grant is all documentation
precisely because we recognized this fact.
- How does the monthly release cycle fit into this plan?
Monthly releases promote stability, and improve public visibility of
the progress of the project.
- How do we tie in the items that are in RT and docs/ROADMAP to the
plan?
The ROADMAP provides some details beyond the grant proposal. RT is
bugfixes, not a project planning tool.
- Given current "staffing" and work remaining, what is your best guess
on a 1.0 release?
The first law of managing open source projects is no dates. I can give
you approximate developer-hours: 1 year of two full-time developers.
We're into about the 3rd month of two full-time funded developers, but
our velocity has been slowed by the process of Chip needing to
assimilate the entire architecture of Parrot in a single gulp. (He's
doing quite well at it too.)
And a few observations (some of which overlap)
- without a detailed description, we won't know when we're done. (The
high level plan obviously helps here, but it's not "pass this test
suite and we're done.").
- Someone I respect very much *cough* said, "but you need a bunch of
small, achievable goals". I don't think parrot currently has this. I
*think* that having a project plan will help here, but having a
project -manager- would be even better.
- Yes, I know you can't map a corporate PM mentality onto an open
source project and have it stick. But I think there's a lot to be used
from more formal methodologies.
There's a deeper philosophy difference here between Agile methodologies
and the more traditional methodologies. Perl and Parrot have always
been Agile projects. So, no, we don't spend months writing up detailed
specification documents, and waterfall charts and Gantt charts. We
won't know we're done when we check off the appropriate number of boxes
(that's a terrible way to gauge code quality anyway). We will know
we're at a stage when we can make a 1.0 release (not exactly the same
thing as being "done") when the 9 critical subsystems are fully
featured enough to support compilers on our major target languages, and
stable enough to be considered production code.
- RT is slow. painfully slow. And not just for leo (for whom it should
be very very fast and stay out of his way.).
I'll talk with Ask and Robert about this. It may be something a
hardware upgrade could solve.
- The Architect is not necessarily the Project Manager. The roles have
been conflated, I think, because most people don't know parrot has
(had?) a PM.
Not really. There was always a clear distinction between Dan's role and
my role. My role didn't require active participation on the mailing
list. My role is changing now, partly because I'm tying up the legal
side of things and getting more time to participate in development
(thank goodness), and partly because the Allison-Chip-Leo team has a
slightly different tone than the Allison-Dan-Leo team (which is
perfectly natural when changing who fills a significant role).
- We need to expose the process along with the code: because of the
nature of our workforce, we need to make it much easier to pick and
choose things to work on.
- When possible, things should be on parrotcode.org; even better if
it's just something from svn-latest that's been automatically
web-ified.
I agree with this. The documentation and webpages have become sorely
out of date in the past year. This is one of Chip's big priorities (as
he mentioned in his talk at YAPC::NA).
So, summarizing, we've identified a big need in the documentation and
public information area. Are you volunteering to help out there? The
first place to start is updating the information on parrotcode.org.
Allison
