Hi. I'm ok with the general proposals made by Herbert. I'm not a huge fan of github myself, but it seems like the most pragmatic choice right now, and I wouldn't know anything else that is clearly better, so I'm in favour. I'd somewhat prefer to have everything (wiki etc) in one place then, but I don't have strong opinions on this topic. Cheers, Andres

On Apr 29, 2016, at 5:25 PM, Alexander Berntsen wrote: especially not SaaSS which theoretically can just get rid of all your data without you having a say.

There is a fix for that — Sandstorm.io https://sandstorm.io/ (self-hosted, not SaaSS) with download-all-data-at-any-time options such as Gogs on Sandstorm https://apps.sandstorm.io/app/d9ygf47xrtnw12j92cyt6cu8ut75esx01u4q3kcrn8415w.... Personally I use it as a secondary storage to public github repositories, and primary storage for personal projects. Cheers, Audrey

Or a phabricator instance ? That might also make sense. On Friday, April 29, 2016, Francesco Ariis wrote:

On Thu, Apr 28, 2016 at 11:56:51PM +0200, Herbert Valerio Riedel wrote:

...

One benefit I see from using GitHub is that this way would we be closer to the Haskell community (given the majority of Hackage packages are hosted on GitHub), and our work would be more transparent for the community as well as offering a lower barrier to participation/contribution.

Moreover, I think GitHub would also help make our efforts/progress towards a revised Haskell Report more visible to the community, which in turn may even provide us the motivation to carry on...

Hello, personally I would be more likely to read/participate in the discussions if such discussions were hosted here or on Trac rather than Github. haskell-prime@ is just one 'subscribe' away, comes in a familiar package to haskell-cafe@ participants (a mailing list) and interface (their mail client); I cannot say the same about Github. Similarly, Trac allows me to follow new issues (new tickets notifications or the life of a single ticket in particular) via rss, without having to register to a new service.

Of course: 1. this is just my experience -- there are many haskell developers on Github and they probably like the workflow there (I would still say the haskell-cafe@ audience is bigger though). 2. I am not a committee member. In the end it's them who are going to pour blood/sweat/tears in the report; whichever tool the committee chooses is the right one

I think the general interplay between mailing lists / wiki pages / Trac issues that GHC uses works well. Specifically: - Mailing list for routine communication. - Trac tickets / Git issues / Phab something-or-other for discussion on a specific proposal. - Wiki page to present a specific proposal. Wiki pages and tickets are therefore often linked together, and sometimes a conversation has to move from the mailing list to a ticket (though rarely the other way around). I specifically vote against using the mailing list to debate well-defined issues that need to be resolved, as it's far too easy to lose signal in the noise and hard to see the thread all in one place. I'm personally agnostic about the decision between Trac/Github/Phab. Richard On Apr 29, 2016, at 9:17 AM, Mario Blažević wrote:

On 04/29/2016 07:15 AM, Francesco Ariis wrote:

...

Hello, personally I would be more likely to read/participate in the discussions if such discussions were hosted here or on Trac rather than Github.

There are two or three distinct components we need to keep track of: the draft standard, discussions, and potentially RFCs.

Discussions can be hosted on this mailing list, on Trac, or as Git issues. Each of them would serve fine, but we should choose exactly one and stick to it. The mailing list looks pretty good in isolation, but the best choice depends on whether we want to have RFCs or not.

If we support Requests for Comments, we'll need to also support their public submissions and Git pull requests or something to the same effect. In that case, at least the inevitable comments on RFCs would best be placed close to the RFCs themselves - if the RFCs end up on GitHub the discussions of them should be kept as GitHub issues.

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On Fri, Apr 29, 2016 at 9:17 AM, Mario Blažević wrote:

There are two or three distinct components we need to keep track of: the draft standard, discussions, and potentially RFCs.

Discussions can be hosted on this mailing list, on Trac, or as Git issues. Each of them would serve fine, but we should choose exactly one and stick to it. The mailing list looks pretty good in isolation, but the best choice depends on whether we want to have RFCs or not.

If we support Requests for Comments, we'll need to also support their public submissions and Git pull requests or something to the same effect. In that case, at least the inevitable comments on RFCs would best be placed close to the RFCs themselves - if the RFCs end up on GitHub the discussions of them should be kept as GitHub issues.

I agree with all of this, and think this distinction should be kept in mind in terms of keeping things organized to whatever tools we choose. For general discussions I think this mailing list is best. I'm cool for keeping irc as a side channel for hashing things out more interactively, but it's all to easy to miss things there so I think it's best kept as a side channel not a main one. I like (something like) GitHub issues for tracking the exact content of proposed changes and their (direct) commentary. As far as the particular tool I'm mostly agnostic, but lean slightly towards github over trac. I've never used phabricator so can't say there (though I'm slightly against, as it'd be another tool to learn.) As far as wiki stuff goes, to be honest I'm kinda against it. I see how it might could be helpful as a sort of staging ground prior to actual RFCs, or as an edited synopsis of email discussion; but in my experience the wiki proposals for Haskell changes tend to get very crufty and hard to follow after a few changes have been made. I think I'd rather see specific versioning on proposals, so it can be clear when/which parts of the proposal are retracted, amended, etc. This may very well be a reason to prefer github, since such development can happen in branches where we can see the iteration of changes prior to merging a specific one into the master branch. /me goes off to read about how Fsharp, Rust, and Go do things -- Live well, ~wren

Some random meta thoughts: I'm generally OK with using some newer, external service over Trac for our work. My impression is that everyone on board is probably OK with starting fresh for this iteration of the committee, and recycling/cleaning up any proposals or data we deem important anyway. The 'technical debt' here is very minimal. So whatever we choose, I think as long as we're happy, it will be OK. I understand the complaint about SaaS/proprietary services, and do think it's important. But I'm not going to cast an enormous vote of strong disapproval or anything if I lose that, or anything. (Getting work done on Prime itself is a more important battle to fight, honestly). Phabricator might have some OK advantages. It's a bit unfamiliar, but does have some technical bonuses, and isn't likely to go away soon thanks to its infrastructure/GHC use: - We can have something like an indexable, persistent IRC room we can all use. I do generally prefer immediate methods of discussion, but asynchronous messaging and persistent logs (even when offline) are an important value add, and IRC fails here IMO. - It has strong access control mechanisms. This means the Prime committee can do things like have private discussion, outside of usual e.g. email. I know people are intimately leery of this, but I think in practice people form private discussion channels anyway, and having private avenues for discussing larger public things in an easy way (chat rooms, tickets etc) is desirable. The lack of a sanctioned private channel IMO will only cause Prime members to discuss in private *anyway*, but in disjoint groups probably. I don't think we should use it all the time, but I can imagine we might want this - I didn't see it brought up. - It has some other useful facilities aside from bug-tracking obviously, like voting tools, which could come in handy for some things. I personally hate using mailing lists for outright voting processes. (For example, see a vote a while back about GHC buildbots: https://phabricator.haskell.org/V3) Note: None of these (except point #2) is important to inspire 'clear superiority', IMO. It's mostly just technical icing on top of the rudimentary things we need. I think #2 is important, but we can use other private means of course. (I'd prefer not to get derailed at all on the meager technical bits above - although I would like to know in general what people think about #2) I do think GitHub would be nice for it's workflow features, however. Phabricator doesn't allow patches with 'git push' yet (it will soon) and I know people get anxious about arcanist. Obviously we value outside input, so 3rd party reach and low friction is an important factor to keep motivation, which Phabricator is behind on. (It's engineered as a long-term productivity tool by the devs - so immediate familiarity is seen as a low cost on the long scale for the vast array of users.) Even then, just the difference in the tool may be enough to deter some people. On that note, I generally think that with a good edit workflow, we shouldn't really need wiki processes at all. I'm with Wren, here - wikis are nice for a draft, but in practice it's very. very nice to have drafts publicly version controlled, in the same way code is. In light of that, an issue tracker for discussion, + a formative patch is enough, I think. I'm reading into the specifics of the Rust/Go/etc RFC process. Python also has a similar one I believe, although PEPs predate these other languages quite a lot, and probably served as their own inspiration, too. So, another useful data point to think about. On Fri, Apr 29, 2016 at 11:31 PM, Gershom B wrote:

On April 29, 2016 at 10:49:38 PM, wren romano (wren@community.haskell.org) wrote:

...

I like (something like) GitHub issues for tracking the exact content of proposed changes and their (direct) commentary. As far as the particular tool I'm mostly agnostic, but lean slightly towards github over trac. I've never used phabricator so can't say there (though I'm slightly against, as it'd be another tool to learn.)

If github makes sense but there is a concern over a permanent record that is not in the custody solely of a private company, then there is a nice tool (in haskell no less) that will pull the various associated data of a repo (including issues) into a branch in the repo itself [1].

We could then script a regular pull of the repo into some common haskell community infrastructure.

Cheers, Gershom

[1] https://github.com/joeyh/github-backup _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On 29/04/2016, wren romano wrote:

For general discussions I think this mailing list is best. I'm cool for keeping irc as a side channel for hashing things out more interactively, but it's all to easy to miss things there so I think it's best kept as a side channel not a main one.

I like (something like) GitHub issues for tracking the exact content of proposed changes and their (direct) commentary.

As far as wiki stuff goes, to be honest I'm kinda against it. I see how it might could be helpful as a sort of staging ground prior to actual RFCs, or as an edited synopsis of email discussion; but in my experience the wiki proposals for Haskell changes tend to get very crufty and hard to follow after a few changes have been made.

I agree on all these points. I lean slightly towards Trac rather than Github myself, being a little wary of enshrining other-party-hosted SaaS in a communal effort like this, but i shan't make a fuss about it. I'm slightly against Phabricator as installing PHP to work on Haskell feels very wrong.

On 02/05/2016, Alexander Berntsen wrote:

FWIW, you'll likely need to use JavaScript regardless what choice is made, so that's not much better. :)

Yes, but i'm already numb to that pain. PHP would be a fresh wound.

I second this motion to call a vote or other concrete, forward-moving action on this topic. I, too, am refraining from commenting on other threads until this issue is resolved. Richard On May 6, 2016, at 12:32 PM, M Farkas-Dyck wrote:

I think we ought to make a choice quite soon. Proposals are already being made on this list, but i hesitate to make comment lest it be forgotten when we move to our new medium.

My opinion on our choice of medium is known, i believe. Who or what makes the final call? hvr? committee member votes? _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Yes, persistent commenting / threading somehow on some tool. And I trust Herbert's judgement On Saturday, May 7, 2016, Vitaly Bragilevsky wrote:

The third one here. I think that process decisions can be made by chairman alone without calling votes, that's organizing part of job, not conceptual one.

Vitaly

On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg javascript:_e(%7B%7D,'cvml','eir@cis.upenn.edu');> wrote:

...

I second this motion to call a vote or other concrete, forward-moving action on this topic.

I, too, am refraining from commenting on other threads until this issue is resolved.

Richard

On May 6, 2016, at 12:32 PM, M Farkas-Dyck javascript:_e(%7B%7D,'cvml','m.farkasdyck@gmail.com');> wrote:

...

I think we ought to make a choice quite soon. Proposals are already being made on this list, but i hesitate to make comment lest it be forgotten when we move to our new medium.

My opinion on our choice of medium is known, i believe. Who or what makes the final call? hvr? committee member votes? _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org javascript:_e(%7B%7D,'cvml','Haskell-prime@haskell.org'); http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org javascript:_e(%7B%7D,'cvml','Haskell-prime@haskell.org'); http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime