| 1 |
On Fri, Jul 28, 2017 at 9:44 PM, R0b0t1 <r030t1@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Not to get away from OP's question, but how good would the installer |
| 4 |
> need to be before it held the interest of any developers that manage |
| 5 |
> the website or handbook? |
| 6 |
> |
| 7 |
|
| 8 |
That is hard to say. I've been meaning to better integrate the |
| 9 |
systemd install guide into the main handbook for ages (to make it more |
| 10 |
like how various bootloaders are supported in the handbook/etc). I |
| 11 |
just haven't gotten around to it. Maybe now that I have a bit more |
| 12 |
time on my hands I will. It sounds like EFI is in a similar |
| 13 |
situation. |
| 14 |
|
| 15 |
A lot of these docs end up being written as standalone docs to be read |
| 16 |
alongside the handbook, and they don't get integrated. There is no |
| 17 |
reason that the handbook can't have branch points at the appropriate |
| 18 |
places. In both the case of systemd or EFI there are probably only a |
| 19 |
few points where somebody has to do something differently so having a |
| 20 |
standalone guide just makes the process more confusing. |
| 21 |
|
| 22 |
There was a proposal the other day to switch these kinds of documents |
| 23 |
over to something other than pure Wiki markup to make it easier for |
| 24 |
users to contribute. A wiki is nice in theory for user contributions, |
| 25 |
but the problem is that many pages are locked down so that normal |
| 26 |
users can't modify them, which defeats the purpose. That means that |
| 27 |
it is actually harder for them to contribute, because they can't just |
| 28 |
fork a document and contribute a pull request. It also makes it |
| 29 |
harder for devs to make big changes because we can't just work on them |
| 30 |
offline and get agreement before changing the main page. |
| 31 |
|
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives