> Therefore, what about "a search system for multiple wiki sites"?
sorry, less information. I mean like this. Google search: "dependent haskell site:ghc.haskell.org/trac/ghc/wiki OR site: wiki.haskell.org" Regards, Takenobu 2016-09-28 21:29 GMT+09:00 Takenobu Tani <takenobu...@gmail.com>: > 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