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 <gersh...@gmail.com> 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/haskell-prime