On Jul 14, 2005, at 12:51, Will Coleda wrote:
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
