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.

The first feedback I received came from a veteran Perl 5 and Parrot contributor who commented, not on the PDS, but on the summary of the Summit I posted the next day on the parrot-dev list. In that summary I confined myself mostly to the three items that had been designated as Roadmap Goals, each of which I described via these categories:

  • Title
  • Subject
  • Team (leader and members)
  • Release Target
  • Further Info

The other developer wrote,


It's kind of surprising that rakudo is not mentioned at all in any of
these roadmap items. Oh, I think I understand how these are supposed to
benefit rakudo, but I also think that if Roadmap Goals are intended to be
part of the public face of the project, it might be worthwhile to be more
explicit about the benefits. Otherwise, the parrot developers run the
risk of reinforcing the notion that parrot is disconnected from its users.

Or, phrased positively, I think it would be very good P.R. to have these
roadmap goals explicitly state how they will benefit rakudo, in a way that
tries to make clear that supporting rakudo remains an important project
priority.


Substitute "high level languages" (HLLs) for "rakudo" in the above, and you get the gist of all the criticism I received about the Summit and the Roadmap Goal process. How do I respond?

On the one hand, I think it's important to note that we're just beginning to implement a new way of working that ties together PDSes, Roadmap Goals, Teams and Supported Releases. The PDSes held in 2008 or 2009 tended to set many roadmap goals years in the future, but rarely held more than one developer responsible for achieving those goals. There was no concept of teams accountable to the project as a whole, so mostly work was done by individual developers without specific reference to goals.

We had no PDS in 2010 until December, and it was only at that meeting that we decided to have quarterly PDSes on the second weekend following quarterly Supported Releases. We came out of that PDS with several "action items," but only one of them (new embedding API) would qualify as a Roadmap Goal in the sense we're now using that term, namely, an objective being worked on by a team of developers (whiteknight and bluescreen) in preparation for the next quarterly Supported Release (3.0).

So, it's not surprising that, when we asked our members to propose Roadmap Goals for 3.3 and later which would be discussed at last weekend's PDS, we failed to explicitly ask them to describe the benefit to Parrot users that would result from the achievement of the Roadmap Goals. Of course, they will be of benefit to Parrot users, but we had not yet imposed on ourselves the responsibility of making that benefit explicit. Consequently, I didn't think to include "User Benefit" as a bullet point in my summary of the PDS.

On the other hand, the criticism is valid. We don't sufficiently factor in the needs and preferences of Parrot users into what we as Parrot developers do on a week-in/week-out basis. We're too indifferent to whether our code is being used or not -- whether information technologists outside of the Parrot loop see Parrot as a useful product or not. We love to write code, and as long as we continue to get good vibes from doing that, we tend not to ask: Is anybody using our code?

There are two, unsurprising consequences of this: We fail to keep our current users happy. And we fail to attract new users. I'll only address the first of these here. I refer you to posts on parrot-dev by Patrick Michaud, pumpking (leader) of the Rakudo implementation of Perl 6. Three posts in particular:

  1. A new NQP roadmap, 2011-01-31: Comment 1
  2. Rakudo needs from Parrot in 2011: Comment 1
  3. Same thread, Comment 7

Patrick is a long-time Parrot contributor himself. In these posts he acknowledges the many improvements in Parrot in the last year. But he also feels that there are many areas where Parrot has not paid sufficient attention to issues identified by Rakudo as impediments to Rakudo's progress. He further feels that if these impediments were overcome, all HLLs would benefit, not just Rakudo. But the Rakudo project, for at least a year now, has felt that to secure its own future it cannot place all its chips in the Parrot basket.

So how should we proceed? It's too bad that we didn't have the first two of those three posts from Patrick before the recent PDS. If we had, we might have been able to identify teams of Parrot developers to work on them and hence qualify them as Roadmap Goals for the 3.3 release in April. But what we can now do is to use that as the basis for formulating Roadmap Goals for 3.6, 3.9 and 4.0. Here is one proposal for a timeline:

  • February: Fully assimilate the discussion at the January 29 PDS, particularly with respect to PCT, NQP-rx, NQP, etc. Evaluate the 4 specific HLL needs cited by Patrick in the second of the two parrot-dev posts cited above. Those of you who have blogs ... blog away!
  • March 15: By this date, have a rough draft of roadmap items to be discussed at the April 30/May 1 PDS for inclusion on the Roadmap for the 3.6, 3.9 and 4.0 releases. That draft should include both:
    • goals which are the continuation/completion of the goals set for 3.3 (e.g., next step for Lorito);
    • goals which reflect our response to user needs such as discussed above. Note: Work can start on these objectives at any time if developers are available and ready to start work.
  • April 1: The draft of roadmap items should now include names of Parrot people who will make up the team working on those items.
  • April 5-19: We'll probably be busy preparing for the quarterly Supported Release on Tuesday, April 19.
  • April 20: Start posting to parrot-dev the "final draft" versions of Roadmap Goals and other action items to be discussed at the next PDS. These drafts should include a "User Benefit" portion.
  • April 30/May 1: [Which day and time TBD] Quarterly Parrot Developer Summit. Set Roadmap Goals for 3.6 and (as feasible) 3.9 and 4.0 release. Goals must identify 2 or more developers working as a team on their achievement.

Rinse; repeat.