Thank you so much. I know I've said it before. But the slides / notes
you've taken the time to write and circulate before have been truely great.
How can I and others help encourage you and others to keep up the great
work on that side?
Good synthesis notes that help orientate new and old
Main discussion is here (
https://github.com/ghc-proposals/ghc-proposals/pull/10).
BTW, I prepared a conceptual web page about following.
> Furthermore, we provide a simple search box for multiple wiki sites.
> (Please wait for a while. I'll prepare simple-conceptual demonstration
with web.)
On 2016-09-30 19:26, Carter Schonwald wrote:
> We all do!.
I dont.
(Sorry, just had to put that Monty Python joke in there. At least I
*think* it was MP?)
Obviously, yes, we all *really* *REALLY* like Haskell, otherwise we
wouldn't be arguing about it, would we? ;)
Regards,
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
Dear Moritz,
Oh, thank you for teaching me.
I'll write to it.
Thanks,
Takenobu
2016-09-30 20:06 GMT+09:00 Moritz Angermann :
> Dear Takenobu,
>
> may I politely direct you to https://github.com/ghc-
> proposals/ghc-proposals/pull/10,
> and ask you to add your comments
Hi,
Richard said:
(1) search engines still find out-of-date documentation
(2) the wiki is not discoverable
I know trac is treasure house.
And I realized old pages are valuable for decision.
My concrete suggestion is here:
For (1):
When we find out-of-date documentation, we directly modify
On Fri, Sep 30, 2016 at 4:14 AM, Richard Eisenberg
wrote:
> I've spent some time thinking about how and what to synthesize from this
> conversation. Moritz has captured much of these ideas in the proposal he
> submitted. Thanks.
>
> But that proposal tackles only one part
I've spent some time thinking about how and what to synthesize from this
conversation. Moritz has captured much of these ideas in the proposal he
submitted. Thanks.
But that proposal tackles only one part of the problem: what to do in the
future. It does not address the insufficiencies of the
Hi Carter,
Thank you very much :)
We love haskell,
Takenobu
2016-09-28 22:29 GMT+09:00 Carter Schonwald :
> I like your perspective on this
>
>
> On Wednesday, September 28, 2016, Takenobu Tani
> wrote:
>
>> Apologies if I’m missing context.
Friends,
after the recent discussion here and on #ghc, I’ve taken
the liberty to extract a small part of this into a
proposal[1]. In essence this does not cover *all* of the
wiki, but the commentary and documentation part, after
Herbert mentioned that would be something he could see
happening.
For me the biggest problem is that each of the three Wiki's has a different
markup syntax.
So the mental motivation to do anything is tempered by having to look up
everything to make sure you are using the right markup for *this* Wiki.
Reducing it to one, wherever it is, would help a lot.
Alan
On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote:
[...]
> 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
I was thinking of what Richard was describing as shoring up the
insufficiencies of the existing infra, rather than something to be
directly targeted in any possible alternative.
Hypothetically could be made automatic or a git hook, if you wanted
things like last-modified timestamps injected into
That is an interesting way to interact with the wiki, I had
never thought about using it that way!
So what you are proposing is a version controlled text based
documentation system, precisely you can download the wiki and
use your own cli/editor finding/indexing tools on it?
This would of course
Makes sense, no problem!
I think my main personal complaints with docs have been:
Poor discoverability — neither wikis nor search solve this, I want a
dir listing.
Slow search — almost every wiki has slow search. bouncing out to
google is annoying. just let me grep.
Broken links — this is
Chris,
I’m all in favor of a better system! My only intention was to point
to a solution that might help with the current system, right now.
I’ve come to use that feature quite frequently even outside of this
specific use case, as many of the results are often full of
interesting yet stale
Just a quick note: Google provides the “Date range” filter found under
search options. This allows to narrow down the date range.
> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote:
>
> On 2016-09-29 04:43, Richard Eisenberg wrote:
>> Here's a pre-proposal (which could
er than a wiki. I can see the force of that. Maybe we should
> consider it.
>
> Simon
>
> From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> Sent: 27 September 2016 15:54
> To: Simon Peyton Jones <simo...@microsoft.com>
> Cc: Sven Panne <svenpa...@gmail.com>; g
; To: Simon Peyton Jones <simo...@microsoft.com <mailto:simo...@microsoft.com>>
>> Cc: Sven Panne <svenpa...@gmail.com <mailto:svenpa...@gmail.com>>; ghc-devs
>> <ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>>
>> Subject: Re: How, precisel
> Simon
> <>
> From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> Sent: 27 September 2016 15:54
> To: Simon Peyton Jones <simo...@microsoft.com>
> Cc: Sven Panne <svenpa...@gmail.com>; ghc-devs <ghc-devs@haskell.org>
> Subject: Re: How, p
I like your perspective on this
On Wednesday, September 28, 2016, Takenobu Tani
wrote:
> Apologies if I’m missing context.
>
>
>
> Potential contributors need information from wiki.
>
> I feel current wiki’s problems are following:
>
>
>
> (a) reachability
>
>
> 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
On Mon, Sep 26, 2016 at 2:27 AM, Richard Eisenberg
wrote:
>
>
> "Accept PRs on GitHub" *is* an answer to this question, but one we have
> revisited several times in recent memory. (I believe https://mail.haskell.
> org/pipermail/ghc-devs/2015-September/009744.html is the
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
Eric Seidel writes:
> Thanks for the link Alan.
>
> I can personally attest to being intimidated by GHC's wiki when I
> started contributing. I think having a review mechanism in place would
> have helped, because then you at least know that one or two other people
> think your
rimarily a technology issue: there is a
>>> genuinely difficult challenge here. How do you build and maintain
>>> up-to-date, navigable, well-organised information about a large, complex,
>>> and rapidly changing artefact like GHC? A wiki is one approach that has
>>>
;
Subject: Re: How, precisely, can we improve?
Just a remark from my side: The documentation/tooling landscape is a bit more
fragmented than it needs to be IMHO. More concretely:
* We currently have *3* wikis:
https://wiki.haskell.org/Haskell<https://na01.safelinks.protection.outl
Just a remark from my side: The documentation/tooling landscape is a bit
more fragmented than it needs to be IMHO. More concretely:
* We currently have *3* wikis:
https://wiki.haskell.org/Haskell
https://ghc.haskell.org/trac/ghc
https://phabricator.haskell.org/w/
Like many of you, I'm sure, I'm saddened by the occasional tone of the recent
exchange about contributions to GHC.
I'd like to move the conversation forward -- and I'd like to do so on a
technical basis.
So, I ask:
How, precisely, can we improve?
I think it would be best to have answers
29 matches
Mail list logo