Infrastructure & Communication

Infrastructure & Communication

Hello Fellow Committee Members!

Following up on the official announcement, here's a few basic things we
should get agreement over before proceeding. First off, I'm hoping we
can manage to avoid confusing email-threading in the interest of finding
information easier lateron in the email archives. To this end, I'd like
to ask you to consider changing the subject of your reply if you realise
that the topic discussed is diverging significantly from the one
advertised in the Subject-header.

I'll start with the following basic topic

## Infrastructure & Communication

Obviously, we have *this* public (archived) mailing list
"[hidden email]". There's also a (registered) IRC channel
"#haskell-prime" on freenode where many of us will probably hang around.

In the past, the Prime committee used Trac (currently
at https://prime.haskell.org/ ) to organise its work.
Trac provides a wiki, source-browser, and a ticket tracker (which is
familiar to GHC developers, and e.g. allows easy migration of
wiki-content to/from the GHC Wiki).

Some time ago, I converted the original Haskell-Report Darcs
repositories into a single Git repository (with branches) at GitHub

However, since Trac has accumulated quite a bit of old content in its
ticket-tracker over the years, and "Haskell 2020" has been coined a
reboot. Maybe it wouldn't be such a bad idea to start over at GitHub,
and consider the Trac instance mostly as a legacy archive of historic
content.

GitHub allows for Git-based workflows, and there's prior art related to
language design we could steal ideas from, for instance:

IMO, GitHub's issue tracker has become flexible enough for our needs and
its integration with Git pull-requests allows to e.g. group together
change proposal description/motivation, discussion, and finaly the delta
to the haskell-report (with inline annotations/reviews) and so on.
(However, I consider GitHub's Wiki-component quite weak. I'm not sure
what to do about that. Maybe keep using Trac's wiki for that?)

Moreover, we can have CI (I've actually set up a TravisCI job which
builds the LaTeX code) for the Haskell Language report drafts.

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...

So...

Does anyone object to using GitHub?

In case there's no objection, which of the existing language-design
GitHub projects do you consider a good fit for Haskell Prime and
therefore worthy of imitation?

Re: Infrastructure & Communication

>
> However, since Trac has accumulated quite a bit of old content in its
> ticket-tracker over the years, and "Haskell 2020" has been coined a
> reboot. Maybe it wouldn't be such a bad idea to start over at GitHub,
> and consider the Trac instance mostly as a legacy archive of historic
> content.
>
>
> GitHub allows for Git-based workflows, and there's prior art related to
> language design we could steal ideas from, for instance:
>
> - https://github.com/fsharp/FSharpLangDesign> - https://github.com/rust-lang/rfcs> - https://github.com/golang/proposal> - (any others noteworthy?)
>

This seems like the pragmatic way forward. And, as you say, there's plenty
of evidence from other language communities that it can work effectively.

> IMO, GitHub's issue tracker has become flexible enough for our needs and
> its integration with Git pull-requests allows to e.g. group together
> change proposal description/motivation, discussion, and finaly the delta
> to the haskell-report (with inline annotations/reviews) and so on.
> (However, I consider GitHub's Wiki-component quite weak. I'm not sure
> what to do about that. Maybe keep using Trac's wiki for that?)
>

I personally have no problem with a Trac wiki. That being said, the Rust
model of having an RFC repo seems to have worked really well for them
and allows for easy discussion and comments from the community at large.
If we choose to go that route I would gladly take the time to gather relevant
info from the Trac wiki and organize it similarly to the way the Rust team has.

> Does anyone object to using GitHub?
>

I think it's great.

> In case there's no objection, which of the existing language-design
> GitHub projects do you consider a good fit for Haskell Prime and
> therefore worthy of imitation?
>

Re: Infrastructure & Communication

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.

Re: Infrastructure & Communication

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/04/16 09:02, Andres Loeh wrote:
> 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.
I'm not on the committee, but I would suggest having everything
available from haskell.org. I'm in general not fond of free software
projects relying on proprietary software; especially not SaaSS which
theoretically can just get rid of all your data without you having a
say. As such, I would recommend at least synchronising or snapshotting
things to haskell.org infrastructure.
- --
Alexander
[hidden email]https://secure.plaimi.net/~alexander-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

Re: Infrastructure & Communication

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

Re: Infrastructure & Communication

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

Re: Infrastructure & Communication

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.

> 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
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

On 16-04-29 09:22 AM, Richard Eisenberg wrote:

> 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 fully agree with this point. I also agree that this particular
discussion is in happening the right venue.

Re: Infrastructure & Communication

> 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.

Re: Infrastructure & Communication

On April 29, 2016 at 10:49:38 PM, wren romano ([hidden email]) 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.

Re: Infrastructure & Communication

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 April 29, 2016 at 10:49:38 PM, wren romano ([hidden email]) 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
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

On 29/04/2016, wren romano <[hidden email]> 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.
_______________________________________________
Haskell-prime mailing list
[hidden email]http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

> 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
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

> 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
> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Haskell-prime@haskell.org&#39;);" target="_blank">Haskell-prime@...
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime