Library_submissions and Call for Maintainers

[Edward Kmett]

We've had a lot of feedback over the last few months trying to get
clarification on the role of the core libraries committee, and on the
libraries@ process in general. In particular, Simon Peyton Jones asked us
in his own rather inimitable manner to make sure that we sat down and
started documenting things. After all, we've now been at this for almost a
year and a half, and have started to figure out what is working and what
isn't.

In response to that feedback, we've recently taken the time to go through
and update the Library_submissions
<https://wiki.haskell.org/Library_submissions> page rather extensively to
better describe and refine the libraries@ process and better define the
role of the core libraries committee.

Changes of note:

* Up until now we've been using the rather ad hoc definition of "core
libraries" as libraries that come with the Haskell Platform and which are
subject to the libraries@ proposal process. We've recently taken it upon
ourselves to clarify this further. To that end we've updated the
Library_submissions <https://wiki.haskell.org/Library_submissions> page
with a detailed summary of what libraries are considered "core" and why.

* It was brought to our attention that figuring out even where to file a
bug report or feature request for a given library was a tricky concern. To
that end we've added information on how to find the appropriate issue
tracker to the form.

Communication:

There are two forms of potential communication breakdowns that we'd like to
address.

We're still working on figuring out a more effective way to communicate
what changes are happening in the background out to the community, lest we
wind up with another situation like the Foldable/Traversable Proposal,
where it caught an appreciable segment of the community unaware. We've
started at least tracking issues that impact modules defined in the Haskell
report in GHC trac with "report-impact", but we still have a lot more to do
on this front.

We have also been asked to help clarify what happens to a proposal once it
leaves the libraries@ mailing list, assuming that the proposal is accepted
by the maintainer. The issue was raised that it wasn't clear when an issue
had been dropped on the floor, and who has responsibility to carry it
forward at each stage along the way. To that end, we've posted some
basic responsiveness
guidelines <https://wiki.haskell.org/Library_submissions#Responsiveness> to
help. We're not looking for a way to hold someone's feet to the fire, but
merely for a way to keep proposals from getting stuck in limbo as they
transition out of the libraries mailing list and into the hands of the
maintainers.

Maintainership:

In an effort to maintain a greater level of throughput on issues that come
along, we're trying to increase the number of projects that have active
maintainers. Some of these aren't necessarily core libraries, but they are
libraries that have been handed to the core libraries committee for
maintenance.

A couple of weeks back we sought out an active maintainer for the directory
package, as it had accumulated several months worth of backlogged tickets,
most of which just needed a clear head to make an informed decision about
how to proceed. Phil Ruffwind and Elliot Robinson stepped up to fill this
gap, and have been making a rather exciting amount of headway in clearing
out the issue backlog, while managing to give those issues the
consideration they are due.

Emboldened by this success, we have a few other packages with which we'd
like to do the same:

* random

We've had some truly excellent work done over the last couple of years on
how to deal with "splitting" a random number generator in a
cryptographically sound manner. I spent some time cleaning up a few
outstanding issues for this package personally over the summer, but have
not had nearly enough time to devote to the issue of how to integrate the
outcome of the recent research on splitting, while simultaneously caring
about performance and soundness.

* unix

We've had a number of issues accrete over time, particularly issues that
have to do with portability to lesser used platforms such as OpenBSD. We've
also had a lot of cooks in the kitchen, so the documentation style for this
library is all over the place. We could use a solid maintainer for this
package who is deeply familiar with unix internals, and who, preferably
would like to deal with bringing some order to these cross platform
concerns.

* Win32

None of us on the current core libraries committee are *particularly* well
versed in current windows issues. We have a new "windows task force" as
well. Would the task force -- or someone involved or who would like to be
involved in it -- be willing to pick this up and carry the torch?

* old-time, old-locale, haskell98 and haskell2010

The old-time and old-locale libraries are primarily maintained because
their contents are mentioned in the Haskell Report, which is/was (mostly)
implemented in the haskell98 and haskell2010 packages. Three months ago, we
determined to stop shipping these as boot libraries with the GHC as a
consequence of the Applicative-Monad Proposal. (Issue #9590
<https://ghc.haskell.org/trac/ghc/ticket/9590>) While Herbert Valerio
Riedel recently started working on a "fully compliant" version of the
Haskell 2010 report, there is a reasonably large design surface in that
area, balancing between perfect compatibility and pragmatic compatibility
with other libraries. These libraries could use a more active official
maintainer.

Thank you for your time. Please do not hesitate to contact me (or reply)
with questions, concerns, or thoughts.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150228/8dff55e5/attachment.html>