[Framework-Team] Re: PLIP deadline overly aggressive?

[Ross Patterson]

Alec Mitchell <apm13 at columbia.edu> writes:

> On Sat, Jun 20, 2009 at 12:15 PM, Ross Patterson<me at rpatterson.net> wrote:
>> Matthew Wilkes
>> <matthew at matthewwilkes.co.uk> writes:
>>
>>> On 20 Jun 2009, at 19:38, Tres Seaver wrote:
>>>
>
>>>> Isn't 4.0 deliberately a "short-hop" release, with minimal new
>>>> feautres,
>>>> mostly intended to move the platform forward (to modern versions of
>>>> Zope, Python, CMF)?  Keeping the window short emphasizes that fact, at
>>>> least to my outsider's eyes.
>>>
>>> Hmm, the way I see it is that the timeline is deliberately short as
>>> 4.0 is an intermediate release.  Trunk is the innovative, new thing,
>>> 4.0 is incremental upgrades that go beyond a 3.x release.  In fact,
>>> the release was almost called 3.5 or similar.
>>>
>>> I don't know how I feel about this, the period is awfully short, but
>>> I'm probably leaning towards short keeps things from getting too
>>> ambitious.
>>
>> To clarify, I'm definitely on board with the spirit of moving quickly.
>> My concern is that in moving quickly we'll end up missing discussion
>> that needed to happen and that without that discussion we'll end up with
>> a release that is technically short-sighted, demonstrates poor
>> consideration of impacts to the wider community, or any other negative
>> that can result from moving too quickly.
>>
>> So maybe we should re-phrase the question.  How fast is *too* fast?
>> What *are* the minimum requirements for discussion of a backwards
>> incompatible major release?
>
> I think it's impossible to know in advance how fast too fast is.
> However, the current deadline was based on a reasonably well attended
> framework team meeting and was an essentially unanimous decision.  The
> rationale was that a PLIP does not require a completed product or even
> thorough design, and therefore does not require a long time to create.
>  Allowing a little under two weeks including two weekends, seemed
> reasonable at the time.  A longer timeframe would have led to
> procrastination as likely as to productivity.  People who aren't
> capable of putting together a one page summary of desired
> functionality with realistic risk assessments in a two week period,
> probably aren't likely candidates to implement such functionality in a
> similarly compressed period (which is an implicit goal of this
> release).
>
> The results, I think, have born that theory out.  We have a large
> number of submitted PLIPs, and though they are of varying quality,
> framework team members (and others) have been providing feedback.  As
> a result, many of the sub-par PLIPs are improving rapidly.  I doubt
> that more time would have resulted in more PLIPs (and I'm not sure we
> really need more PLIPs).  It may have allowed some extra time for
> discussion and brought forward a better proportion of high-quality
> PLIPs, but judging by what's currently in Trac and how quickly it's
> improving, I don't believe that's a major issue either.  My guess is
> that with a longer timeframe, most PLIPs would start coming in around
> the time we started sending reminder emails and the results would have
> been nearly identical.
>
> We will be having a meeting early this coming week to discuss the
> submissions and the review process.  If we determine that we have not
> received enough quality PLIPs or that there are obvious gaps in what
> we have, I don't see why the submission deadline couldn't be extended.
>  I don't believe that will be the case, judging by the current
> submissions, but I speak only for myself.  Further, I hope and expect
> that framework team members (and others) will be commenting on those
> PLIPs to further discussion and help clarify PLIP goals and
> feasibility.  That process is likely to continue until the final
> review deadline next weekend; hopefully with continuous feedback from
> the PLIP authors and participants.
>
> None of the deadlines are currently set in stone, and they can be
> extended as needed.  However, the goal is to have a limited, mostly
> backwards compatible, release with significant infrastructure
> improvements and enough user facing improvements to merit the "4.0"
> name.  We also aim is to make the release in a fairly short timeframe,
> and that will be taken into account when making decisions on PLIPs.
> We currently have a diverse set of PLIPs with many different authors
> and varying levels of ambition.  This is undoubtedly a good thing.
>
> No decisions have been made at this point, and the process seems to be
> working well.  I suggest we see it through for the next week before
> deciding whether or not there are major problems.  However, active
> involvement by framework team members and PLIP authors is going to be
> critical for this compressed timeframe to work.  I dedicated a full
> day this week to providing feedback on submissions, and I plan to do
> the same for the next week.  I hope other Framework Team members are
> willing to put in similar effort, and if they do,  I think this
> process will be successful.

I was, of course, at that meeting and I agreed with the decision.  After
that meeting, as I've been following the PLIP process, this question
that had been percolating up in my mind and apparently Joel's as well.
I've had the sense not enough discussion is happening, and I've had that
sense even keeping in mind the if-you-extend-it-they-will-procrastinate
effect.  There's a threshold beyond which more time results only in more
procrastination but there's also a threshold beyond which less time
results in loss or absence of valuable perspective and consideration.

But as I said, and I think Joel said something similar, I don't feel too
strongly either way. +-0 for keeping the deadline and evaluating whether
it's been sufficient as it's approaching... or whenever, so long as the
evaluation is made.

Ross