[ghc-steering-committee] Redid our documentation

[Simon Marlow]

I like the new organisation.  One functional difference I noticed: the new
description says that we assign a shepherd when the proposal starts the
review process, but under the existing process a shepherd is assigned to
each proposal when the PR is created (but I guess we haven't been sticking
to this?).  Ideally I think we'd assign shepherds earlier because it will
streamline the review process: the shepherd will spot things that should be
clarified or addressed before the rest of the committee gets involved.  I
think it's likely to be a better use of resources.

This also addresses the question about labels: if each proposal has a
shepherd, then the shepherd will notice when the proposer adds a comment to
the PR requesting review, and can formally start the process with the rest
of the committee.

Cheers
Simon

On 26 February 2017 at 04:26, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> [I sent this mail from Monday to the wrong address, second try]
>
> Hi,
>
> there was a bit confusion about our documentation, so with SPJ’s
> blessing I went ahead and restructured it a bit. For now, this is only
> on a branch and not live yet:
>
> https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructur
> ing
>
> Note that it starts with a concise timeline of a proposal, and from
> there has links to section answering specific questions, within the
> same file. What was three files before (README, process, committee) is
> now all in here (with the exception of the “detailed instructions” for
> the Github-novice, which is in a separate file). This should make it
> easier for everyone involved to know who has to do what when.
>
> Our process is, however, flawed: We ask authors to set labels (“Under
> Discussion” and “Under Committee Review”), but they do not have
> permissions to do so. So this does not quite work.
>
> So I suggest the following change:
>
>  * What was “Under Discussion” is now simply any PR that does not have
> any other label. This way, when opening discussion, nothing concrete
> has to be done. Which is easier. (GitHub allows to list all PRs that
> have no label, so there is no loss in functionality here.)
>
>  * When the author wants to submit the PR, he sends a mail to this
> mailinglist (is this set up to accept mails from non-subscribers?) and
> it its the task of the shephard to set the label to indicate that that
> the committee has accepted to review the proposal. (At this point, the
> shephard could for example set the `Out-of-scope` label instead.)
>
>
> If there are no complains I will adjust the docs-restructuring branch
> accordingly and then move that to master.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170227/15a2bfcc/attachment.html>