jkeenan's blog

Parrot 3.6 Release Quotation Contest Is Over

The release quotation contest is over. We received four submissions, each of which was correct. In order of receipt, they were from:

  1. Ville Koskinen
  2. Lucas Buchala
  3. Daniel S.
  4. Javier M. Mora

Each of the four submissions appears to have met the do-not-use-the-Internet condition for researching the answer. In fact, each of the four appear to have gotten the answer the old-fashioned way:

They remembered it!

Parrot at YAPC::NA::2011, Asheville NC

There is no substitute for face-to-face contact.

Salespeople have to meet their customers in person. Marketing alone will never suffice.

Politicians have to press the flesh. Television ads will never suffice.

Open-source software projects' developers have to meet F2F. IRC will never suffice.

That's the main lesson I draw from YAPC::NA::2011, just concluded in Asheville, North Carolina.

"Do It for Python!"

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?"

Feedback on Jan 29 2011 Parrot Developers Summit: Were Users' Needs Served?

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.

Preparing for January Parrot Developers Summit

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?

On Roadmaps and Teams, Part Three

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.

On Roadmaps and Teams, Part Two

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.

On Roadmaps and Teams, Part One

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?

Reflections on Parrot as Project, Product and Process

Last week I helped organize a gathering of Parrot developers, old and new, in Portland, OR. We shaped the discussion more around the people of the Parrot project rather than the technology or the code. Since my return to New York City my time available for Parrot has been tied up with diagnosing problems impeding Parrot's build on small resource machines. So I haven't had time to write up my reactions to the gathering.

Pacific Northwest Parrot Developers Gathering: Summary

Summary of Pacific Northwest Parrot Developers Gathering
Saturday, October 16, 2010
Portland, Oregon

Part One Discussion
Please see the list of discussion questions posted here.

Syndicate content