Infrastructure & Communication

[wren romano]

On Fri, Apr 29, 2016 at 9:17 AM, Mario Blažević <blamario at ciktel.net> 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