Haskell Platform package additions: decision time!

[Duncan Coutts]

On Tue, 2009-09-15 at 09:34 +0100, Malcolm Wallace wrote:
> > So far we have had a few people send in comments (thanks  
> > particularly to
> > Ian and Simon) but a few more would not go amiss, even if it's just
> > "yes".
> 
> Basically, yes.
> 
> > Concern 1: "The policy document itself is too long and too detailed."
> 
> I must admit, I too did not read it fully, because it was  
> intimidatingly long. In fact, it made me think "phew, thank goodness  
> I didn't want to propose any of my packages for the platform!"
>
> > Quick poll: should we split the rationale into a separate page or keep
> > it on the same page? Yes or no.
> 
> Definitely split off the rationale,

Seems like this is the majority opinion. If it is actually putting
people off then that's certainly a good reason to split. The procedure
is not very complicated, the policy is just fairly detailed and, I hope,
fairly clear. We were trying to anticipate questions and corner cases.

> and similarly, the "how to". (Actually, the latter seems to have
> already been split out, but there are remaining dangling pointers to
> the old in-page location.)

Fixed the broken link, thanks.

> >      * Disadvantages: slower to jump back and forth between the policy
> >        and the rationale (the two are fully cross-referenced)
> 
> Suggestion: can the rationale be coded to come up in a separate  
> browser window? (Especially if the links ensure that different  
> rationale links come through to the _same_ target window.)  I would  
> find it helpful to be able to see policy + rationale side-by-side  
> (although not intermingled).

I've no idea how to do that in the trac wiki markup. If anyone knows
please say so.

> > Concern 2: "Documentation written for the proposal will get lost."
> > ... by attaching it as a condition of
> > the package being accepted, that we ensure that it does actually get
> > done rather than nice docs languishing where no users will find them.
> 
> My question is who enforces this, and how?

The how is by making it a condition of acceptance for the package. The
policy describes conditional acceptance:

        A package is considered as conditionally accepted if, by the
        discussion deadline, the libraries mailing list reaches
        consensus to accept it on condition that further minor changes
        are made. The agreed changes must be made before the package is
        included in any release. If these changes are made in time for
        the normal package freeze dates (as set by the release team)
        then the package is considered as accepted. If the changes
        cannot be made in time for the immediate major release but are
        made in time for the subsequent major release then the package
        is considered as accepted for that subsequent major release and
        does not need to be re-reviewed.

As for who would suggest making it a condition in any particular case,
well any reviewer or member of the steering committee. If people
complain that it's an unnecessary condition then we point to the section
of the policy (as yet unwritten) that says it's a presumed condition.

Sound like enough?

> > Concern 3. The more major and general complaint Ian has is that he
> > believes the criteria for acceptance should be essentially a  
> > checklist.
> 
> > So my suggestion on this complaint is that we go with the policy that
> > the steering committee has proposed and that we move quickly  
> > afterwards
> > to discuss more comprehensive package requirements and guidelines.
> 
> If the aim is gradually to formalise a checklist, by first examining  
> the packages we want in the platform, then abstracting the  
> characteristics that make them desirable, then it sounds fine.   
> Perhaps the _goal_ of forming an incomplete checklist should be  
> explicit in the first few rounds of package consideration.

Sure, we can make that clear.

> Ultimately, I think package proposers will benefit from having a clear  
> statement of what they must do to improve their package's "fitness".

Indeed. We want to get to the stage where maintainers can do much of the
assessment themselves before even getting to the review stage.

Duncan