<div dir="ltr"><div>There's no need to keep them on a separate page.</div><div><br></div><div></div><div>If the purpose of keeping them around (on the same or on a separate page) is to make people aware that these methods exist, putting them away on a separate page achieves none of the goals (near to no awareness) and has the same drawbacks in terms of effort required.</div><div><br></div><div>It's sufficient to keep them on the same page in a separate section. If you are clean and organized, nobody will be confused or distracted.</div><div><br></div><div>Ivan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 Apr 2022 at 14:29, Bardur Arantsson <<a href="mailto:spam@scientician.net">spam@scientician.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 03/04/2022 20.10, Tom Ellis wrote:<br>
> On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote:<br>
>> On 03/04/2022 19.34, Tom Ellis wrote:<br>
>>> Well, good question, but back at you: who are you discouraging from<br>
>>> Haskell by keeping a large number of complex, unmaintained, possibly<br>
>>> completely wrong, installation instruction on the Downloads page?<br>
>><br>
>> I have no strong feelings either way, but would it perhaps be viable to<br>
>> just leave that "Alternative installation options" as a simple link to a<br>
>> separate page perhaps be sufficent to guide people to use either of the<br>
>> two 'main' options while still leaving the alternatives semi-documented?<br>
>> Has that been considered?<br>
>><br>
>> (I think just adding a disclaimer that the 'alternative methods' are not<br>
>> supported per se, but perhaps simultaneously encouraging corrections<br>
>> might be a way to lessen the maintenance burden?)<br>
> <br>
> The problem that I am trying to solve is that no one with maintenance<br>
> responsibility for the <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a> website knows if those alternative<br>
> installation methods work, are up-to-date, are currently supported by<br>
> the (external) teams that put them together, etc..  It is not doing<br>
> right by the community to publish information that we cannot support<br>
> or verify.<br>
> <br>
> If someone is willing to be the "owner" of a particular installation<br>
> method, to ensure it is kept up to date and high quality, then we'll<br>
> keep it!  To reiterate what I said in my first email, we can ...<br>
> <br>
> "Keep (some of) the alternative installation options and find<br>
> community volunteers to maintain them. The volunteers will be<br>
> responsible for ensuring verifying on a regular basis that their<br>
> instructions are still working, submitting timely corrections when<br>
> necessary, and responding promptly on the issue tracker to questions<br>
> about their installation instructions"<br>
> <br>
<br>
I did read the OP. My point was simply that it might be acceptable to<br>
have half-working (or whatever) instructions if they were squirreled<br>
away behind a link + disclaimer. That might be better for people who<br>
(for whatever reason) don't want either of the officially supported methods.<br>
<br>
Regards,<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>