Process proposal: Require explicit user-oriented timelines in library proposals

[Ben Gamari]

Edward Kmett <ekmett at gmail.com> writes:

> Everything that the CLC has in the works that affects the Prelude already
> has been brought up most of the way to this standard, in that
> https://prime.haskell.org/wiki/Libraries/Proposals gives the summary of the
> resulting timeline with the outstanding proposals worked out in in a user
> facing manner.
>
> It doesn't enumerate the explicit actions the user should take at each step
> to build in whatever the 3 release compatible mode would be at any given
> point, however. Help on that front would be welcome.
>
I would love to pitch in however it doesn't seem that users outside of
the committee have write access to wiki.

> A few details change if the Simons choose to ultimately roll -Wcompat into
> -Wall, as the 3 Release Policy takes a bit of a hit, but the general
> timeline remains intact.
>
Right. However, keep in mind that it's possible that the Three-Release
Policy may take a hit even if -Wcompat remains independent due to GHC's
stance on -Wall stability.

> My primary concern is that if we ask end users who put forth proposals for
> excruciating detail that considers everything in the 3 release policy, we
> limit ourselves to proposals that come from people already deeply familiar
> with the process.
>
> The current mindset is that if we do choose to adopt a proposal once the
> community has agreed to the broad strokes, we'll need to do what we can to
> raise it to this level and incorporate it into the roadmap.

Right; I'm not suggesting that a proposal must meet this standard to
even be considered. Rather, as you said, I would like if this standard
were enforced on proposals by the time they are adopted.

Really, my critique is mostly on the presentation of this information.
It's possible for a user to determine the implications of a given
proposal with what is on the wiki currently, but it's not as easy as it
could be.

> Currently we're doing so with respect to Prelude-affecting changes, but
> spreading this (or something weaker) out to the wider set of core libraries
> is something we could consider doing once we get a sense of how well it is
> working in practice, and if there is a general sense that the stability it
> brings outweighs the rather significant delays it imparts to the process.
>
> Keep in mind we already have plans that stretch out to GHC 8.6 as a
> consequence of the 3 Release Policy. Almost all significant changes will
> now take around 4 years to play out. Around the Prelude that seems about
> right. Around the rest of the core libraries that would likely become a
> rather significant pain point.
>
Indeed.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160214/13c7046d/attachment.sig>