We all do!. And I really appreciate your clear positive suggestions around "what are we trying to understand or ask our selves"
no matter what conclusions we come to this day / month / year, its something we will need to revisit (and should) every once in a while. change happens, as does "growth" (for various notions of growth :) ) On Sep 29, 2016 7:37 AM, "Takenobu Tani" <takenobu...@gmail.com> wrote: > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald <carter.schonw...@gmail.com>: > >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani <takenobu...@gmail.com> >> wrote: >> >>> Apologies if I’m missing context. >>> >>> >>> >>> Potential contributors need information from wiki. >>> >>> I feel current wiki’s problems are following: >>> >>> >>> >>> (a) reachability >>> >>> "Where is the page I need?" >>> >>> >>> >>> (b) outdated pages >>> >>> "Is this page up-to-date?" >>> >>> >>> >>> (c) update method >>> >>> "How Can I update the page?" >>> >>> >>> >>> >>> >>> About (a): >>> >>> >>> >>> It's difficult to find pages they need. Maybe reasons are following: >>> >>> * We have multiple wiki sites. >>> >>> * Desired contents structure is different for each member. >>> >>> >>> >>> So single wiki site is not enough from latter. >>> >>> >>> >>> Therefore, what about "a search system for multiple wiki sites"? >>> >>> >>> >>> >>> >>> About (b): >>> >>> >>> >>> Haskell's evolution is fast. >>> >>> New contributor encounters sometimes outdated pages. >>> >>> But they don't still know how to correct them. >>> >>> >>> >>> Therefore, what about putting "outdated mark" to the page by them? >>> >>> >>> >>> They can easily contribute. >>> >>> And if possible, they send update request with any way. >>> >>> We’ll preferentially update many requested pages. >>> >>> >>> >>> >>> >>> About (c): >>> >>> >>> >>> We have multiple wiki sites. Someone is unfamiliar about them. >>> >>> Github is one of the solutions for new contents. >>> >>> But I don't have idea about this for current contents. >>> >>> >>> >>> Regards, >>> >>> Takenobu >>> >>> >>> >>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg <r...@cs.brynmawr.edu>: >>> >>>> I'm quite leery of using a new site (readthedocs.org), as it creates >>>> yet another platform for contributors to understand. Reducing the number of >>>> platforms has been a fairly clearly-stated goal of these recent >>>> conversations, as I've read it. >>>> >>>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>>> reason against moving: we lose the Trac integration. A Trac wiki page can >>>> easily link to tickets and individual comments, and can use dynamic >>>> features such as lists of active tickets. These are useful and well-used >>>> features. I don't know what's best here, but thinking about the real loss >>>> associated with moving away from these features gives me pause. >>>> >>>> Richard >>>> >>>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan <mgsl...@gmail.com> wrote: >>>> > >>>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel <e...@seidel.io> wrote: >>>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>>> one >>>> >>> thing that’s easier about a wiki is that the editing process is >>>> much more >>>> >>> lightweight than making a PR. >>>> >>> >>>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>>> pencil >>>> >>> icon in the top-right. It allows you to make arbitrary changes in >>>> the >>>> >>> file and then automates the construction of a PR. The owner of the >>>> file >>>> >>> can then accept the PR very, very easily. If the editor has commit >>>> >>> rights, you can make your edits into a commit right away. No need to >>>> >>> fork, pull and push. >>>> >> >>>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>>> >> rendered and inter-linked pages *and* have the option for web-based >>>> or >>>> >> git-based editing. Though, based on my limited experience with GitHub >>>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>>> > >>>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>>> > tried using GitHub wikis, and found that they were clunkier than just >>>> > having wiki / docs in your repo. GHC would probably want to have a >>>> > separate docs repo, as otherwise the commit history will get filled >>>> > with commits related to proposals, etc. >>>> > >>>> > It may be worth considering a similar approach with the GHC >>>> > documentation. We've had great success in stack with using >>>> > https://readthedocs.org/ . The way this works is that you have a >>>> > branch that readthedocs points at ("stable"), which provides the >>>> > current version to display. I realize that ghc would want to have >>>> > multiple versions of the docs up, but I'm sure that's feasible. >>>> > >>>> > Github itself has pretty nice markdown rendering, and the ability to >>>> > edit directly. Note that there is no GitHub lock-in here - it is just >>>> > a collection of markdown files, organized however you like them. >>>> > >>>> > The risk with such a migration is that the old wiki(s?) don't get >>>> > fully migrated and shut down. If that happens, then information will >>>> > be even more spread out and hard to find. Perhaps we can use pandoc >>>> > to automatically migrate much of the wiki content to markdown? It >>>> > probably will not be a lossfree conversion. >>>> > >>>> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >>>> >> seems to offer the same set of features, but apparently with a more >>>> >> traditional (and I assume customizable) layout. >>>> >> >>>> >> I think having the option for simple, immediate edits or >>>> peer-reviewed >>>> >> edits (the peer-review is much more important to me than having an >>>> >> explicitly file-based system) would be a big win. Perhaps there's >>>> even a >>>> >> trac module that implements something like this? Then we could >>>> decouple >>>> >> it from the question/task of migrating the existing content >>>> elsewhere. >>>> >> >>>> >> Eric >>>> >> _______________________________________________ >>>> >> ghc-devs mailing list >>>> >> ghc-devs@haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> > _______________________________________________ >>>> > ghc-devs mailing list >>>> > ghc-devs@haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs