Contribution vs quality, and a few notes on the Platform process

[Simon Marlow]

On 09/11/2010 01:16, Ross Paterson wrote:
> On Mon, Nov 08, 2010 at 10:13:34PM +0000, Ian Lynagh wrote:
>> One criticism that I feel I've seen a lot, about the standard libraries
>> of many languages, is that they are inconsistent; [...]
>>
>> My hope is that the Haskell Platform can avoid this, and therefore that
>> we will use a process that helps us avoid it.
>
> That the process should address such concerns is a logical consequence
> of the current model of the Haskell Platform as a sort of standard,
> making choices on behalf of users.  This model seems to be unworkable.
>
> An alternative model would be like a Linux distribution: a selection
> of package versions that have been tested to work together on different
> platforms.  Packages would have to meet the package requirements listed
> on the AddingPackages page (all fairly objective), but would not have
> to have distinct functionality or meet any other subjective criterion.
> The test for inclusion (or retention) would be involve weighing the
> number of users of the package against its maintainance cost.
>
> That would be unlikely to produce consistency, but it seems more
> workable.

So the current situation is that anyone can nominate packages for 
inclusion in the platorm, which implies that the maintainer is not 
involved at all - the HP just decides whether or not to include the 
package in its current state.

I'm wondering whether a better way to run the process is to have the 
maintainer more involed in the process of nomination.  Instead of 
nominating a package for inclusion in the platform, a mainatiner would 
"donate" a package for inclusion.  By doing so they would also be 
implicitly relinquishing some of the responsibilty for the design of the 
package to the community.  This is the way I think the platform should 
work - it's not just a quality control on packages, but a process by 
which we build a sound baseline set of APIs for Haskell development.  In 
order to do that, we need to have the community responsible for the 
whole of the platform, not just the entry bar.

I admit that balancing the responsibilities of the maintainer with the 
demands of the community could be tricky.  We don't want it to be a 
one-sided affair where the maintainer has to fix all the bugs while 
accommodating every demand from the community to change APIs.  So 
presumably the expectation would be that the maintainer also devolves 
some of the responsibility for maintainership to the community too - 
there would be some benefit to being in the platform, more eyes on the code.

This is moving in the opposite direction from what Ross suggests above - 
making the platform less of an aggregation mechanism and more of a 
single community project.  Could it work?  I'm not sure.  Clearly Ross's 
model would "work", but it would produce something that's less like a 
platform.

Cheers,
	Simon