Mobilizing PM groups for parrot..
Will Coleda
parrot?
(Resending from correct account)
Will Coleda
Hey, Allison - you drafted up the project plan for TPF grant for
parrot, neh?
Are you the defacto Project Manager for parrot? Or is that position
unfilled?
On Jul 12, 2005, at 6:56 PM, Allison Randal wrote:
> On Jul 12, 2005, at 13:51, Will Coleda wrote:
>
>
>> Anyone have any ideas on how you might harness a PM group to work
>> on parrot?
>>
>
> Harness them to do what? Write tests? Clean up documentation?
> There's certainly precedent (Phalanx), but you need a bunch of
> small, achievable goals.
>
> Allison
>
>
>
Allison Randal
> Anyone have any ideas on how you might harness a PM group to work on
> parrot?
Harness them to do what? Write tests? Clean up documentation? There's
Will Coleda
Allison Randal
>
> Hey, Allison - you drafted up the project plan for TPF grant for
> parrot, neh?
Yup. With a good deal of input from Dan, Leo, Patrick and others.
> Are you the defacto Project Manager for parrot? Or is that position
> unfilled?
Indeed I am. Parrot and Perl 6. Jesse Vincent has also taken on the
role of assistant project manager lately.
Allison
Will Coleda
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 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?
- How does the monthly release cycle fit into this plan?
- How do we tie in the items that are in RT and docs/ROADMAP to the
plan?
- Given current "staffing" and work remaining, what is your best
guess on a 1.0 release?
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.
- RT is slow. painfully slow. And not just for leo (for whom it
should be very very fast and stay out of his way.).
- 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.
- 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.
- 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.
Nicholas Clark
> I have a .. few.. questions for you. Hopefully none of them are
> *overly* snarky. Some progress has been made dealing with issues like
Being snarky on a public mailing list is not a good way to win friends an
influence people. You have a lot to learn in this area, I see. Do not forget
that when dealing with volunteers, they are just that, and have the ability
to take umbrage and drop everything there and then.
Nicholas Clark
Allison Randal
>
> 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
Will Coleda
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)
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.
Allison Randal
>>
>> http://dev.perl.org/perl6/people.html
>
> Perhaps we need a similar page on parrotcode. =-)
Seems unnecessary to maintain it in two locations, but you could link
to that one from parrotcode.org.
> 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.)
I'm pragmatic. If it's working well enough for the people who are using
it, keep using it. Quick show of hands who finds it useful to have TODO
tasks in RT? And how many find it makes it harder to dig up the bugs
and patches, and harder to tell when we're doing a good job of keeping
bugs down? (Not impossible, as RT has very powerful searching, just
difficult enough to be an irritant.) I expect this to be about a 50/50
split, but could be wrong.
Whose responsibility is it to go through and clean out the TODO tickets
that aren't accurate any more because the specifications changed?
Yours? Are you happier working on that than on ParTcl?
> 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)
I highly recommend you read The Pragmatic Programmer, and chromatic's
Extreme Programming Pocket Guide. It sounds like you're trying to fit a
round peg in a square hole and getting frustrated because it doesn't
fit.
> I blame the Cabal. =-)
There is no cabal. :)
Okay, I say that flippantly, but it's also true. There is a group of
people who do lots of stuff. You know what it takes to be part of that
group? Do lots of stuff. :)
> 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.
That's reasonable. Even desirable. In the very early days of the
project, the mailing lists were designed to each have one central "go
to" person. It's an efficient way to get stuff done.
> 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.
Yup that's the plan. Parrot is actually ahead of most of the rest of
the project in terms of what gets public. I can't think of much in
Parrot that hasn't been on the mailing list. Dan was good about making
the list the primary place where work happens.
The more significant problem is things that were on the mailing list a
long time ago, but never made it into a more permanent document. Or,
things that made it into permanent documents, but are now out-of-date
with the current state of the code or design.
> As I've argued to Leo on IRC, I'd like to see goals like this
> documented more at #2.
So document it.
> 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 imagine so. It's not really designed for that.
> 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.
If you want to improve public access to Parrot information, don't talk
about how someone should do something, just do something. There are
plenty of things you can do without direct input from Chip, Leo, or me.
(Which isn't to say we aren't working on things, just that a
non-blocking solution will get more work done overall.) One big task is
to read through the current documentation, try following it in a
literal-minded way and figure out where it doesn't match the actual
state of the code. Then submit a patch for the documentation. Some
documentation patches don't need to change the description entirely,
but just make clear what features are done already and which are
planned for the future.
If digging through Parrot guts to figure out how it works isn't your
thing, there are lots of more general things to look for in the
documentation. You've been on the list long enough to have a general
idea where things are heading. There's cruft lying around, like the
cvs.perl.org front page. You can comb over the website, locate the
cruft, and submit patches.
You could take responsibility for converting Dan's blog posts into
documentation. It would be valuable to have that information in the
repository (with his permission). And a good first step before updating
the information in light of later changes (I mean Dan's changes over
time, as much as anything). I'd suggest not turning them into TODOs.
> 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.
More outdated than missing. But some missing too. Are you volunteering?
Allison