New Github features and Haskell Prime

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

New Github features and Haskell Prime

Haskell - Haskell-prime mailing list
Hello prime people,

Github recently added a board-style overview over tickets and small notes. I
think this is a great addition, and converted all current PRs to board items.

There is no shortage of things to be considered for Haskell Prime, and I find it
hard to think of them all. For things I’m somewhat interested in seeing a
proposal for, I created notes that are not yet tickets, but serve as a reminder
to consider them at some point.

I’d like to invite you all to add your language extensions and ideas to the board
in the pre-proposal column. Even if you don’t have the time to write a proposal,
someone else might see the note and decide to do so instead.

See you at https://github.com/haskell/rfcs/projects/1

Greetings,
David/quchen



--
My GPG keys: https://keybase.io/quchen


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

M Farkas-Dyck-2
I see we have a "Last call" column. What are its semantics? What are
the criteria for moving an RFC into it? Once there, can the RFC be
moved back out? Has it a time limit when an RFC there must be either
merged or closed? How shall we choose whether to merge or close?

If no one has an idea yet, i propose this:
• A Committee member can move to nominate an RFC by making a comment
to that effect. If no comments have been made on the RFC since,
another member may then move the RFC to "Last call".
• Once in "Last call", an RFC remains for 1 week while further
comments can be made and committee members cast votes for either
"Merge" or "Close". Open question: shall we vote openly in the
comments or by some other system TBD?
• At the end of the voting period, if a majority of the committee (not
merely of those who voted) votes to merge or close, we do so; else we
move the RFC back to "In discussion".

I formulated this procedure so no one member could push an agenda
unilaterally, but to break the stall in progress i have been feeling
here. Alternative proposals welcome.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Haskell - Haskell-prime mailing list
I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process.

Anyway, here's the gist behind the columns when I created them:

Pre-proposed is for things nobody cared enough about to write the proposal. The idea is that pull requests/proposals should be created from each.

Proposed is where things start being tracked as actual proposals with rst files and what have you. These are invitations for everyone to participate in the discussion.

In discussion is to single out the tickets with the most traffiic for those who want to get am overview of current events. When the discussion stalls the ticket might move back a column.

Last call means that, ideally, every committee member (and whoever else is interested) should do a final proof-read of the proposal. Things in this column are considered good and final by the participants in the discussion before, and if there is no objection, that's what goes into the report.

The last column is to show what made it into the report pipeline for some time for our less frequent readers.

Greetings,
David/quchen


On 22 September 2016 19:43:12 CEST, M Farkas-Dyck <[hidden email]> wrote:

>I see we have a "Last call" column. What are its semantics? What are
>the criteria for moving an RFC into it? Once there, can the RFC be
>moved back out? Has it a time limit when an RFC there must be either
>merged or closed? How shall we choose whether to merge or close?
>
>If no one has an idea yet, i propose this:
>• A Committee member can move to nominate an RFC by making a comment
>to that effect. If no comments have been made on the RFC since,
>another member may then move the RFC to "Last call".
>• Once in "Last call", an RFC remains for 1 week while further
>comments can be made and committee members cast votes for either
>"Merge" or "Close". Open question: shall we vote openly in the
>comments or by some other system TBD?
>• At the end of the voting period, if a majority of the committee (not
>merely of those who voted) votes to merge or close, we do so; else we
>move the RFC back to "In discussion".
>
>I formulated this procedure so no one member could push an agenda
>unilaterally, but to break the stall in progress i have been feeling
>here. Alternative proposals welcome.

--
Sent from my cellphone. Please excuse my brevity.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Richard Eisenberg-4

> On Sep 22, 2016, at 5:08 PM, David Luposchainsky via Haskell-prime <[hidden email]> wrote:
>
> I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process.
>

I think having a formal process aids in transparency, something that some in our community feel is lacking. I therefore think that we should indeed have a formal process. If the process ends up tying our hands behind our back, then we change it!

I like the process suggested by M.

Richard

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Matthias Fischmann-3
On Mon, Sep 26, 2016 at 05:05:05PM -0400, Richard Eisenberg wrote:

> Date: Mon, 26 Sep 2016 17:05:05 -0400
> From: Richard Eisenberg <[hidden email]>
> To: David Luposchainsky <[hidden email]>
> Cc: M Farkas-Dyck <[hidden email]>, Haskell-prime Mailing List
>  <[hidden email]>
> Subject: Re: New Github features and Haskell Prime
>
>
> > On Sep 22, 2016, at 5:08 PM, David Luposchainsky via Haskell-prime <[hidden email]> wrote:
> >
> > I did not plan this out too much. I would say let's use common sense rather than setting up processes. The columns are to give viewers an overview for our open process.
> >
>
> I think having a formal process aids in transparency, something that some in our community feel is lacking. I therefore think that we should indeed have a formal process. If the process ends up tying our hands behind our back, then we change it!
>
> I like the process suggested by M.
i agree, and would like to propose an independent ratification
process.  the following is all from me listening to people who have an
intimidating amout of experience with this.  icfp is great!  (-:

everybody can sign up to the ratification process with email and a few
lines on who they are and why they care.  once the standard is
finalized, everybody gets to vote.  nay-voters have to (are allowed
to?) submit change requests that would compell them to vote yay.

if the proposal gets 70% yays it becomes law, and nobody gets to
complain that they haven't been asked.

if the proposal falls short of the 70%, the change requests are
reviewed and negotiated into a new proposal.  this is hoped to take
less effort than the original draft, but still enough to discourage
people from frivolously opposing ideas they don't like but can live
with.

ratification is important for acceptance in the wider community.
scheme set the bar at 50% and the standard came through with 51%,
which didn't convince the nay-sayers much to embrace the it.

curious how you all feel about this-
m.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

signature.asc (212 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Richard Eisenberg-4

> On Sep 26, 2016, at 8:47 PM, Matthias Fischmann <[hidden email]> wrote:
>
> i agree, and would like to propose an independent ratification
> process.

At the risk of sounding exclusionary, I wonder what the goal of defining the committee is if the larger community can vote on each proposal. As I understood it, the committee has voting rights, while the larger community has viewing and commentary rights.

We *do* most certainly value wide input. But voting is quite sensitive. In particular, you recommend a threshold of 70% before something is accepted. 70% of what? Of votes? Who is eligible to vote? And how do we publicize a vote? When is it held? What if that period of time is a big holiday in some country? Etc. It all seems to be a can of worms.

Richard
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Matthias Fischmann-3
On Tue, Sep 27, 2016 at 11:34:02AM -0400, Richard Eisenberg wrote:

> Date: Tue, 27 Sep 2016 11:34:02 -0400
> From: Richard Eisenberg <[hidden email]>
> To: Matthias Fischmann <[hidden email]>
> Cc: Haskell-prime Mailing List <[hidden email]>
> Subject: Re: New Github features and Haskell Prime
>
>
> > On Sep 26, 2016, at 8:47 PM, Matthias Fischmann <[hidden email]> wrote:
> >
> > i agree, and would like to propose an independent ratification
> > process.
>
> At the risk of sounding exclusionary, I wonder what the goal of defining the committee is if the larger community can vote on each proposal. As I understood it, the committee has voting rights, while the larger community has viewing and commentary rights.
>
> We *do* most certainly value wide input. But voting is quite sensitive. In particular, you recommend a threshold of 70% before something is accepted. 70% of what? Of votes? Who is eligible to vote? And how do we publicize a vote? When is it held? What if that period of time is a big holiday in some country? Etc. It all seems to be a can of worms.
>
> Richard


hi richard,

thanks for your reply.  i don't have a strong opinion and there may well be more productive uses of the committee's time, so i'm happy to drop idea.

just to be clarify for those who are still interested: i'm not suggesting we should *change* the process as much as *extend* it.  once the committee has finalized haskell-prime, ask everybody (literally everybody) for a boolean.

this gives the community a way to formally support the outcome in addition to people and process.  and the committee has an incentive to take community feedback serious.  (which, as a downside, also means it's distracting even before the finalized standard is out.)

anyway.  never mind.  (:

thanks,
matthias
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: New Github features and Haskell Prime

Francesco Ariis
On Wed, Sep 28, 2016 at 10:09:56AM +0900, Matthias Fischmann wrote:
> just to be clarify for those who are still interested: i'm not
> suggesting we should *change* the process as much as *extend* it.
> once the committee has finalized haskell-prime, ask everybody
> (literally everybody) for a boolean.

I am pretty sure that everybody in this thread already knows, but
just to clarify how Scheme proceeded: the vote was held on the
mailing list and a template was given, like

    Name:
    Location:
    Organisation (optional):
    Contact (optional):
    Vote:
    Rationale:

As you would expect the quality of voting (example [1]) was much
much higher than "1 like = 1 monad".

[1] https://web.archive.org/web/20140601050807/http://lists.scheme-reports.org/pipermail/scheme-reports/2013-April/003310.html
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime