There is a phabricator module, ponder [1], which looks suitable for the Q&A feature. Surely we all agree that it is easier to setup this module than to host a completely separate service ourselves! This also has the advantage of being able to reference commits, differentials and tickets in an easy manner. Another question about administration, it doesn't seem like many people have permissions to modify the phabricator installation. How easy is it to give some people more elevated positions to deal with things like updating the home page, giving badges, moderating "ponder" and so on? The homepage hasn't been updated for quite a while, the "recent events" tab makes it look like the project is quite dead. If anyone has ever talked to me about this, it should be clear that I am a massive phabricator fanboy and think that we should utilise it more. There are lots of modules [2] that we don't use and the product is just going to get better as other companies (ie facebook) continue to drive it. I think that in the future it would be beneficial to port the wiki and bug tracker from trac to the corresponding phabricator features, phriction and maniphest respectively. Firstly, I think phabricator is just better than trac but the primary reason is that trac is not very actively developed. So three separate thoughts in this email, only one of which is relevant to the thread. With regards to the other points in Simon's email, I don't feel qualified to opine too much as GHC is the only "large" project I have contributed to. Bear that in mind when reading my comments inline below. I'll make sure to check out the video when it is released as well. [1]: https://secure.phabricator.com/ponder/ [2]: https://secure.phabricator.com/w/starmap/
· Doc bugs. Two kinds
o Typos. Friction stops me
o Explanations needed e.g. read/show
The biggest friction is the fact some of the user guide is generated so you have to build the whole compiler to build the user guide. It seems like it would be possible to just not include this generated section if you wanted to compile the guide in order to check you didn't make a syntax mistake or something. Perhaps it would be good if the build bots made the generated user guide available for each build it did. I don't know how feasible this is.
· Lightweight pushes
What does this mean?
· Make user manual into its own repo, to make it easier to take pull requests. But that makes it harder when making synchronised changes to GHC and user manual.
Submodules are annoying to update, everyone knows this. Separating out the two makes synchronous updates harder to review together but makes drive-by updates easier. I think it would be nice if there was a web-interface which allowed people to edit the user guide in the browser rather than have to setup an entire development environment.
· Auto-push: Ability to push to Phab and have it committed automatically if it validates.
This seems like a reasonable idea but perhaps not worth the effort needed to set it up. My usual workflow is to put most of my commits onto phabrictor with the thought that it's better for less people to directly interact with the main branch. If Ben would prefer less control then I can merge more things myself without issues!
· Style guides. Is having a defined style solving a problem we don’t really have? One piece of guidance: adhere to the style of the surrounding code. Low priority.
I think a consistent style wouldn't be a bad thing. The code is a bit strange as Simon perfers the semi-colon style which not many people other than him in the whole community uses. The more pressing concern to me is the scale of the API to some modules is very large, there are lots of exposed functions which aren't documented at all which do slightly different things with subtle invariants. A much more beneficial change would be to enforce that new library style functions should get haddock comments saying what they do! Cutting back these APIs is hard as it requires a very good knowledge of the compiler which not many people have.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs