Patrick R. Michaud wrote:
On Mon, Jan 31, 2011 at 11:59:44AM -0500, Peter Lobsinger wrote:
Get away from PIR (and we're
working to provide you the tools to do this), and you most likely will
not have this issue.
If I may channel Jim Keenan for a moment: Is there any estimate as
to which Parrot release will offer these tools? Will it appear on
the Parrot roadmap as a goal Parrot is committed to providing between
now and 4.0? Are there any preliminary design documents or discussion
that describe what these new tools might look like?
If kid51 may channel Jim Keenan for a moment:
To review what Roadmap Goals are all about:
Unlike our practice at Parrot Developer Summits (PDS) in 2008 and 2009,
we now apply fairly strict criteria for designating some objective as a
Roadmap Goal.
1. The goal is significant enough (as measured in eventual benefit for
our users) and/or complex enough that the Project recognizes that it
will take the combined efforts of two or more developers to reach the goal.
2. The goal is one that the Parrot project as a whole has committed to
deliver in a specified quarterly supported release.
3. As a consequence of (1) and (2) we don't designate an objective as a
Roadmap Goal unless and until we can organize a *team* of developers to
work on it. Each such team has a designated leader. Team members are
responsible to the project as a whole for achieving the goal by the
release date. The project as a whole is responsible to Parrot users for
achieving the goal by the release date.
In other words, for Roadmap Goals we take on a higher degree of mutual
and public accountability than we do for all other objectives. And
since we're just getting our feet wet at this higher degree of
accountability, our Roadmap Goals are going to be relatively few in
number and carefully selected. That selection process ought to include
preliminary discussion on blog posts, a summary posting on parrot-dev in
the weeks before the quarterly PDS and thorough discussion at the PDS.
After the PDS, the teams ought to start work on the Roadmap Goals, and
the team's members have to make certain they don't work on other
objectives *at the expense of* the Roadmap Goals.
Now, I fully expect that, notwithstanding all of the above:
(a) Most of the work in the Parrot project will continue to be done, as
it always has, by individual developers who may or may not be able to
meet an objective by a particular supported release date. That work is
and will always be invaluable -- but the Project as a whole can't commit
to deliverables when only one developer is working on a particular
objective.
(b) Most of the work being done in the Parrot project on a given day
will be in support of objectives other than Roadmap Goals. We hope that
in a given supported release we achieve *many* objectives, not just
Roadmap Goals. But, given the all-volunteer nature of our project, the
only ones we're going to put on the roadmap are those for which we can
deploy a *team* of developers.
(c) Some of the Roadmap Goals will be achieved well before their
targeted release dates.
(d) Some of the Roadmap Goals will actually be a series of goals. For
example, the IMCC Isolation and Lorito Prototype goals set at this past
weekend's summit are both set for delivery in Parrot 3.3 on April 19.
But if you read whiteknight's and cotto's posts, it's evident that there
will be more work needed to reach these goals. So we'll probably set
the next part of this work as Roadmap Goals for 3.6 on July 19.
So let's get concrete. Parrot will have to develop in certain ways --
mostly yet unknown or undecided -- in order to accommodate Rakudo's
needs between now and January 2012? Where do our principal user's needs
fit into this concept of "Roadmap Goal"?
1. As I inferred from backscrolling through #parrotsketch today, it
will probably take us two or three weeks to determine what we have to do
specifically for Rakudo and what we have to do that Rakudo needs but
that all potential Parrot users need as well.
2. Once we have a general idea of what we have to do, we have to refine
this into a list of specific objectives, i.e., the type of tasks we can
formulate in Trac tickets.
3. Once we have specific tasks, we have to canvass our membership to
see which *teams* we can recruit for which tasks. Those tasks can go on
the roadmap for 3.6, 3.9 and 4.0 -- but not for 3.3, because we've
already made our public pledges for that release. If a particular task
is targeted for 3.6, we can start work on it now provided that it
doesn't impeded our work on 3.3 Roadmap Goals.
4. If a particular 3.6 task is ready before 3.6, it can go in whenever
it's ready -- even before 3.3 -- but again, provided it doesn't divert
us from achieving the 3.3 Roadmap Goals by April 19.
5. It's quite possible that there may be an important Rakudo-oriented
objective for which we can only recruit a single developer. We'll try
to achieve that objective -- but we won't put it on the roadmap unless
we can put a team of two or more developers on it. (And, of course,
since there are at least five Rakudo/NQP developers who are also Parrot
developers and commit-bit-holders, there's nothing to keep those folks
from forming a team to work on objectives that would be very beneficial
to Rakudo.)
We're trying to nudge ourselves more in the direction of taking
collective responsibility for producing a finished product that is
useful for Rakudo and other HLL users. Encouraging ourselves to
function on task-oriented teams, and not just as a collection of solo
developers, is an important means to that end. And having tried
Unrealistic Roadmap Scheduling, we're now trying Realistic Roadmap
Scheduling.
What do we hope to achieve by this? Well, in words of the poets,
"You can't always get what you want,
You can't always get what you want,
You can't always get what you want,
But if you try some time, you just might find
You get what you need."
Thank you very much.
kid51
Some additional thoughts:
1. I suspect that much of the Rakudo discussion will take place between
Andrew Whitworth, as Parrot Project Manager, and you as Rakudo Pumpking.
But I think we've reached a point where Parrot ought to have a "Client
Relationship Manager" for Rakudo and for Rakudo to have a similar
relationship manager for Parrot.
2. Our 3.3 release on Tuesday, April 19 falls on the second night of
Passover. This implies that we may want our effective deadline for the
3.3 Roadmap Goals to fall several days earlier.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
