Ah, thank you for your quick reply!
On Jul 14, 2005, at 2:56 PM, Allison Randal wrote:
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
Perhaps we need a similar page on parrotcode. =-)
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.
Ok. Does parrot/perl6 have a project planning tool? Should we move
all the TODO items *out* of RT, then?
It would be helpful if someone looking for a simple thing to work on
could browse *all* the work queues, and not have to worry about
whether something was broken or just undone.
(note that we *can* track a huge amount of this kind of information
in RT, including estimate project durations. Robert has said that he
can generate reports of the information in here. So if there isn't
something else, it *might* be worthwhile to pursue RT. But my goal is
merely to have it tracked consistently, not have it tracked in RT.)
- 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.)
I completely agree on durations instead of dates, and that's how I
should have phrased the question, apologies.
Even with no specific developers assigned to tasks, this is the sort
of thing someone could get quickly from say, an MS Project file.
Which I'm guessing you have something like. ^_^ (or, say, a custom RT
report)
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).
I blame the Cabal. =-)
I see four (extremely roughly categorized) levels of communication
here as far as parrot goes.
0 - things on the level of Allison/Dan/Chip/Leo.
1 - things on the p6i list OR things on IRC (not necessarily
overlapping)
2 - things on the parrotcode site OR things on RT.
3 - things that get to, say, slashdot.
I spend most of my time on level 1 there. All of my interaction
during the Dan-Time with anyone "in charge" was with Dan. It was
natural (for me) to assume Dan was responsible for such things in the
absence of other information.
While I agree not everything needs to go all the way to level 3, I
think (and you've said as much in your blog recently) that we need to
get more of level 0 at least down to the next level. Er, up. Er, out.
- 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).
Yup. Very happy to see this in his notes.
As I've argued to Leo on IRC, I'd like to see goals like this
documented more at #2.
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.
Well, I have worked on this in the past, but have gotten a lukewarm
response. I've been trying to get things into RT and tracked,
including the point releases (which has proved fruitless).
I'd be willing to do more, but, as you've said, "not all of it is
written down". This makes it very difficult for a recording secretary
to do anything with. And if you're going to write it down anyway;
let's keep it in the repository to boot, then it's basically a one
time cost to get it on parrotcode.org - I'm more than happy to send
patches to Robert that point to (and help organize) new documentation
files. That part's easy.
On the plus side, for the most part, documentation that is in
currently in SVN is on the web site. If there is any missing, this is
a bug and should be fixed.
Can you send me what you have on the project plan, and suggestions
for how to proceed with tracking TODOS if we're not going to use RT
for this purpose?
Regards.
