
Hello, what is the status of the discussion about how we should collaborate? I am not picky and would be happy to use whatever tools others prefer. If it was left to me, I'd use: 1) a git repo on github, which contains the current version of the report, and various proposals, and 2) this e-mail list for discussion. As I said before, I think it might be quite nice as a first step to standardize something simple, and hopefully not too controversial, so that we can all familiarize ourselves with the basic process. -Iavor

Hello! On 2016-05-31 at 19:50:54 +0200, Iavor Diatchki wrote:
what is the status of the discussion about how we should collaborate?
I am not picky and would be happy to use whatever tools others prefer. If it was left to me, I'd use: 1) a git repo on github, which contains the current version of the report, and various proposals, and 2) this e-mail list for discussion.
Coincidentally, GHC HQ is considering to revamp its process for proposals as well, so I was holding off a bit to see what would come out of it, as there's an understandable desire by GHC HQ to ideally share a similiar/compatible process with the Haskell language+library committee to make it easier to migrate proposals between the organisations. After all, proposals starting out as GHC extension proposals are often submitted with the agenda to re-propose them for inclusion into the standard once they've been battle-proven. Specifically, a variation of the Rust RFC process is being flirted with, so that's quite similiar to what you're suggesting. While there were concerns about GitHub being a proprietary service, I see little harm, since there's APIs to extract/backup the relevant data from GitHub. However, I'd strongly advise to not mix the report-git repo with the proposals git repo, as that would result in a messy Git history. I'd rather suggest to have 2 Git repos, to keep the concerns separate. And I think we can just start out with such a 2nd GitHub repo and make the process up as we go. At this point we should just get moving, as I sense many of you want to finally start writing up proposals! If this turns out to be a bad idea, we can just call it an instructive failed experiment, and move the content into some other form. If there's no objections, I suggest we create a https://github.com/haskell/rfcs repository with a similiar basic structure to https://github.com/rust-lang/rfcs and see how far we get with that...
As I said before, I think it might be quite nice as a first step to standardize something simple, and hopefully not too controversial, so that we can all familiarize ourselves with the basic process.

On 31/05/2016, Herbert Valerio Riedel
I'd rather suggest to have 2 Git repos, to keep the concerns separate. And I think we can just start out with such a 2nd GitHub repo and make the process up as we go. At this point we should just get moving, as I sense many of you want to finally start writing up proposals!
If this turns out to be a bad idea, we can just call it an instructive failed experiment, and move the content into some other form.
+1 all this.
If there's no objections, I suggest we create a https://github.com/haskell/rfcs repository with a similiar basic structure to https://github.com/rust-lang/rfcs and see how far we get with that...
So will we all become members of the Haskell organization on GitHub?

On 2016-06-01 at 08:41:05 +0200, M Farkas-Dyck wrote: [...]
So will we all become members of the Haskell organization on GitHub?
Yes; there's already been a CLiC team for quite some time: https://github.com/orgs/haskell/teams/core-libraries-committee and I've set up a dual https://github.com/orgs/haskell/teams/core-language-committee team as well which I'll start to sending out membership invitations soon for if we can agree on doing this. Also noteworthy is that GitHub doesn't force you to use its Web-UI for commenting on pull-requests or replying to comments. You can also use email (if you prefer that) for replying to GitHub pull-requests or to comments you got delivered via email. Of course, this doesn't replace the mailing list, nor does it fully replace GitHub's UI which allows e.g. for inline commenting/annotating diffs/code while reviewing.
participants (3)
-
Herbert Valerio Riedel
-
Iavor Diatchki
-
M Farkas-Dyck