Re: Infrastructure & Communication

[Henk-Jan van Tuyl]

On Sun, 01 May 2016 00:22:44 +0200, Austin Seipp 
wrote:
:

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

:

Previous committees used a mailing list for this, the most recent one is:
haskell-2011-commit...@haskell.org

I am not saying we should repeat this, just mentioning the option.

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Carter Schonwald]

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  > 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 > > 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
>>
>> ___
>> Haskell-prime mailing list
>> Haskell-prime@haskell.org
>> 
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Vitaly Bragilevsky]

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  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  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
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Richard Eisenberg]

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

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

Re: Infrastructure & Communication

[Austin Seipp]

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 (w...@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/
___
Haskell-prime mailing list
Haskell-prime@haskell.org

Re: Infrastructure & Communication

[wren romano]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Richard Eisenberg]

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

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

Re: Infrastructure & Communication

[Mario Blažević]

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

Re: Infrastructure & Communication

[Carter Schonwald]

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
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Francesco Ariis]

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



signature.asc
Description: Digital signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Audrey Tang]

> 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  (self-hosted, 
not SaaSS) with download-all-data-at-any-time options such as Gogs on Sandstorm 
.
 

Personally I use it as a secondary storage to public github repositories, and 
primary storage for personal projects.

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

Re: Infrastructure & Communication

[Andres Loeh]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[José Manuel Calderón Trilla]

Hello,

First of all, thanks for all your effort in setting this up!

On Thu, Apr 28, 2016 at 5:56 PM, Herbert Valerio Riedel
 wrote:
>
> 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?
>

I'm a big fan of the Rust model myself.

Thanks again for your effort in getting all this off the ground,

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

Infrastructure & Communication

[Herbert Valerio Riedel]

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
"haskell-prime@haskell.org". 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

 - https://github.com/haskell/haskell-report

This repo is setup to be mirrored to

 - https://git.haskell.org/haskell-report.git

which in turn is also accessible from within Trac at

 - https://prime.haskell.org/browser


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?)

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?

Any other comments/suggestions?



Cheers,
  HVR


pgpmKJtfNsHa9.pgp
Description: PGP signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime