Nor is there any embarrassment in the fact that we're ridiculous, isn't it
true? For it's actually so, we are ridiculous, light-minded, with bad
habits, we're bored, we don't know how to look, how to understand, we're
all like that, all, you, and I, and they! Now, you're not offended when
I tell you to your face that you're ridiculous? And if so, aren't you
material? You know, in my opinion it's sometimes even good to be
ridiculous, if not better: we can the sooner forgive each other, the
sooner humble ourselves; we can't understand everything at once, we can't

On behalf of the Parrot team, I'm proud to announce Parrot 3.2.0,
also known as "Nanday Parakeet". Parrot
is a virtual machine aimed at running all dynamic languages.

Parrot 3.2.0 is available on Parrot's FTP
site, or by following the download
instructions. For those who want to hack on Parrot or languages that run on top of Parrot,
we recommend our organization page on GitHub,
or you can go directly to the official Parrot Git repo on Github

Always store beer in a dark place.
—Robert A. Heinlein

On behalf of the Parrot team, I'm proud to announce Parrot 3.1.0 "Budgerigar"

Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 3.1.0 is available on Parrot's FTP site, or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using the git repository to get the latest and best Parrot code.
(git clone git://github.com/parrot/parrot.git).

Those who have known me for the past decade may be thinking, "Jim Keenan is a
Perl programmer. Why would he want anything done for Python's sake?"

Over the last week I've been gathering feedback on the January 29 Parrot Developers Summit (PDS). Some of this feedback came by reading posts on parrot-dev; the balance came via email correspondence and telephone conversations with several Parrot developers. Here I share some of that feedback and how I think it should affect the way we organize ourselves in pursuit of our goals and objectives over the coming year.

Next weekend we'll be conducting our quarterly Parrot Developers Summit. This summit is important because it will set our roadmap goals for supported releases in April, July, October and January 2012. In preparation for this summit, this weekend I'll be speaking with other Parrot Foundation directors and with the Project Architect. These are the kind of questions I'll be asking (and which I expect them to ask of me):

1. How do you assess the general state of the Parrot project at this time?
2. How do you feel about your own participation in the Parrot project at this time?
3. Within the last four months you assumed the role of Parrot __________. How has that changed your participation in the project? How would you characterize your functioning in that role?
4. In my parrot.org blog posts, I have argued that the project needs self-identified teams and that its roadmap goals should exclude any that are not being pursued by such teams. Do you agree with this argument?
5. Assuming you agree with the argument, what teams now exist within the project?
6. Assuming you agree with the argument, what should be our roadmap goals for 3.3, 3.6, 3.9 and 4.0? Who are on the teams that will pursue those goals? Who leads those teams?
7. To the extent that you do not agree with the argument, what alternative ways of organizing the project should we pursue?
8. How do we encourage the participation of people in the Parrot project if their primary interests or talents are not the roadmap goals?

"I think my imagination's broke. Lemme try and think up the best thing ever. Umm... beef... stew. Yup it's busted alright. I'm gonna go... place."
- Strong Bad

On behalf of the Parrot team and an enthusiastic but undiscriminating dachshund that followed me home last week, I'm proud to announce Parrot 3.0.0, also known as "Beef Stew", or at the insistence of a shadowy government organization, "Snowflake". Parrot is a virtual machine that dreams about running all dynamic languages everywhere, even the one you're think about right now. Parrot has big plans, even if needs a haircut and sometimes goes outside with its shoes untied.

In my last post I argued that over the medium term:

• Parrot needs to attract production users.
• Production users need production-ready features.
• Production-ready features are the only goals which qualify for placement on our roadmap.
• Roadmap goals must have teams dedicated to their achievement.

Let's think through how these principles will affect our roadmap planning.

In my last post, On Roadmaps and Teams, Part One, I argued that the only goals we should put on our roadmap are those which:

• we, the Parrot Project as a whole, are absolutely committed to deliver; and
• for which we have a team committed to delivering those goals.

There are many things which would be great to have in Parrot, and the more developers we have, the more of them we can achieve. But roadmap goals are different from all other goals in that the Parrot Project as a whole is promising to deliver on them; and the Project has organized teams of developers working to deliver on those promises. If we can't organize a team to work on a particular goal, then that goal does not qualify for placement on the roadmap.

As I hinted at the end of my last post, I'm taking a strong stand on this because otherwise we will never create a virtual machine that other software developers will be enthusiastic about using. Note the word 'other' in the previous sentence. In this context, 'other' developers mean people who don't want to 'work on' Parrot, who couldn't care less what's 'inside' Parrot, but who want to 'use' Parrot as the basis for dynamic languages and other applications.

I agree with most of what Christoph Otto posted earlier this month on roadmap items. But I think the relationship between roadmap items and the teams of Parrot developers who will work on those items needs a sharper focus. Here are my thoughts:

• The Parrot Developer Summit to be held on the weekend of Jan 29-30 must set roadmap items for next 4 supported releases.
• Roadmap items are those we pledge, to ourselves, our users and the world, to deliver in the specified releases on the specified dates.
• Roadmap items should therefore be few in number and have strong support among our developers. Few enough that we can under-promise and over-deliver.
• We need to draw a sharp distinction between roadmap items and everything else. Absolutely no "wishlist" or "nice to have" items may go on the roadmap. None whatsoever! There is no such thing as a "secondary" or "second-tier" roadmap item.
• Because of our high degree of commitment to roadmap items, we cannot consider anything for placement on the roadmap unless it has a team of people committed to implementing it.

So what do we mean by 'team' with respect to roadmap items?