Re: Infrastructure & Communication

2016-05-09 Thread 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

2016-05-07 Thread 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

2016-05-07 Thread 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

2016-05-07 Thread 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

2016-05-06 Thread M Farkas-Dyck
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


Re: Infrastructure & Communication

2016-05-03 Thread M Farkas-Dyck
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.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Infrastructure & Communication

2016-05-03 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/05/16 09:30, M Farkas-Dyck wrote:
> I'm slightly against Phabricator as installing PHP to work on
> Haskell feels very wrong.
Try . YMMV.

FWIW, you'll likely need to use JavaScript regardless what choice is
made, so that's not much better. :)
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXKFVTAAoJENQqWdRUGk8BxfsQAO9OhV5GXCquyDtAnHGUMu9l
i/4VMW6HsV8GrQ+Hdlyj9UXwP72oS3liNQUtM7YTIkz8WuMIeqt8fnxEbx18l28d
zFj58LkC8QyvAg4Rtfxopw4KAHifEDCsK+aRbH0V7hVJxqwVKSthvgFyqpaPnJ4n
+T+1jYZthkCOuQh9gHdqZoD6s9dTCtfUvqWQgRtLQ8Z8tVB9rxVPQ/CO16Hq9wmK
KnppKsELCKxyuPz0P5m+biFj+WYLWSVZcyFSOHnjZO4ZKOQ1bvP8FVlv1iADLc5f
kU6sxy7aShZ8VXBO9CPneiYTt7ykchHCTcjXtYZMMWCjPe2RSQ+sfryzCMOq8Arl
G5jDOu4Az2QkG5vbfrxi8Z9+fHEm7Z0S+634P5khJnc/CcPmkYcGb/Dejq1qTbjG
rBUMc9mh/1LNHdyzvPujgi4jXp40NbBBfQ3yOm45Sk7LBPjnQSuj3/NI+arqgbw0
TeChg3phWD5X4VYxmmOFNZYFqaU07m0zDryrx/+iNUesDh2mnwksIKuVtA3iyHW5
HxhcuK2Ehii/Xk+OKJ80VssGd4ZuIXDI6CffIPaWbrt2TLIbwQUeKczR3n98Oy82
Dcmw1WZJC+kpfhb/SMOIcI4RIQCj5XSSwXWSXeN1js0GEQ56ZREQGZhxYI90bwPG
lC+QWGZ2gP8YUbIA/ISg
=4qAY
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Infrastructure & Communication

2016-05-03 Thread M Farkas-Dyck
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.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Infrastructure & Communication

2016-04-30 Thread 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/has

Re: Infrastructure & Communication

2016-04-29 Thread Gershom B
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


Re: Infrastructure & Communication

2016-04-29 Thread 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

2016-04-29 Thread Mario Blažević

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.





I'm personally agnostic about the decision between Trac/Github/Phab.



	I'm leaning toward GitHub for RFCs myself, mainly because of the fork & 
pull request paradigm. Collaborative Wiki editing doesn't have such a 
clear division of responsibilities.


	The main question is, do we want the RFCs as part of the process, or 
just the draft standard and discussions thereof?

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


Re: Infrastructure & Communication

2016-04-29 Thread 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

2016-04-29 Thread 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

2016-04-29 Thread 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

2016-04-29 Thread 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

2016-04-29 Thread 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

2016-04-29 Thread Alexander Berntsen
-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
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXIyiaAAoJENQqWdRUGk8Bo3kQAIjKgP3oyhR78O5u6x1Jjadr
+QBuSrOaB3tTqBfnocoGR5pBPiIeSXRfGUi6lQnLrT54pkr+z/0U/GLp7HCY1RtL
oJjJt4Y1CGt0i9bSah93Uw2eupp08crlIQaGBZ+JgYFkQdxRU2GK8KpW/sn0lUnk
bUI1l9egIYIz48YEaKx5qs4Bp7XNeD7mqBLP/FhmwD86GxcULws408GLf8sS6mN2
S/4qg0vtj0YCKDNrg6VdzV2eUfo+0QNShT54+3pOWlXgdxn3/JcEmxpLKCPsuwdl
3r86SJWsA+QRfLTbyBKsbBydOiF/VZlCe1xIi2zHwEojWGUyprkV7G6J2vBcPmEy
rMW4Vp4AcsqxbvOXyJSqm6f7vTpEGkepM1YcgyNRqs0GRKRaivIwStw2V3nDIl78
2tc7xEURlcoewy/RqE41MLH3zHXjZ/6fd+UYOU/mV2hktjysC67nQ2v+zEJ3MY6A
N090PGMI3kamd0ByyzSwkwJ4sgj5FH5+AxtJ2Eb7YN/kAw9jnGauusTpF54P83ia
t+fFEgUkdYz7bFHKYXD3MvD33jh+f2rmWo9Ow0cxI5JS+5TrwyIDBjHD6dJf4KuJ
AV6/abZJ2VZ7nJxjWPUXz2kYwmKfarQFWL+LXwhaV3xHASld1HhJeS22TpdmFY2p
UcRFHbFuzpSeSeWHOnDg
=eClD
-END PGP SIGNATURE-
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


Re: Infrastructure & Communication

2016-04-29 Thread 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

2016-04-28 Thread 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