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 <gershomb at gmail.com> wrote:
> On April 29, 2016 at 10:49:38 PM, wren romano (wren at 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 at 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/