1 |
Hello, |
2 |
|
3 |
On Tue, Sep 12, 2017 at 9:04 AM, Michał Górny <mgorny@g.o> wrote: |
4 |
> W dniu pon, 11.09.2017 o godzinie 21∶59 -0500, użytkownik R0b0t1 |
5 |
> napisał: |
6 |
>> Hello friends, |
7 |
>> |
8 |
>> On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny <mgorny@g.o> wrote: |
9 |
>> > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael |
10 |
>> > Orlitzky napisał: |
11 |
>> > > On 09/11/2017 01:08 PM, Michał Górny wrote: |
12 |
>> > > > Hi, |
13 |
>> > > > |
14 |
>> > > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather |
15 |
>> > > > than Wiki, put in a nice git repo. |
16 |
>> > > > |
17 |
>> > > |
18 |
>> > > I generally agree with you that wiki markup is terrible and that a text |
19 |
>> > > editor and a git repo is The Right Way to do things (with Jekyll or |
20 |
>> > > whatever to push it to the web). But in my experience, crappy and easy |
21 |
>> > > is a better way to get people to contribute. When I've taken wiki |
22 |
>> > > documents and moved them into git repos, more often than not I become |
23 |
>> > > the sole contributor, and otherwise-technical people just start emailing |
24 |
>> > > me their contributions (which decrease greatly in frequency). |
25 |
>> > |
26 |
>> > [...] |
27 |
>> > |
28 |
>> > Then, you can just take www.gentoo.org and run it locally. It takes |
29 |
>> > a little more effort but jekyll is really trivial to set up and run |
30 |
>> > locally. Then you see it exactly how it's gonna look on g.o. |
31 |
>> > |
32 |
> |
33 |
> I'm going to reply to the Gollum topic here since it's the first mail |
34 |
> according to date. |
35 |
> |
36 |
|
37 |
There is a thread in gentoo-dev where I proposed the Handbook be |
38 |
maintained with Gollum. I apologize if it was not visible, but I was |
39 |
trying to not make a nuisance of myself. |
40 |
|
41 |
>> I previously suggested Gollum and think I should suggest it again. |
42 |
>> Gollum provides features relevant to a Wiki setting including web |
43 |
>> editing. |
44 |
> |
45 |
> Firstly, a generic request to everyone. If you want to suggest that we |
46 |
> are supposed to use your-favorite-tool instead of the one we have |
47 |
> deployed for a few years now, then please include: |
48 |
> |
49 |
|
50 |
I believe I addressed all of these. Please make suggestions on my |
51 |
writing so I can make it more readable if you have the time. |
52 |
|
53 |
If I suggest a project I think it reasonable to expect you to refer to |
54 |
that project's README. Here is a link: |
55 |
https://github.com/gollum/gollum/blob/master/README.md. |
56 |
|
57 |
> 1. A short summary including: |
58 |
> |
59 |
> 1a. How it fits into the desired workflow. Topics such as access control |
60 |
> and caching are of particular interest to me. |
61 |
> |
62 |
|
63 |
It manages a Wiki using a Git repository. Access control is managed |
64 |
through the Git repository and has Git's limitations. When using |
65 |
Gollum it seems like access control is best done by creating |
66 |
repositories. The web editor seems to lack authentication. |
67 |
|
68 |
Gollum may have issues with caching[1]. Gollum is deployed by GitHub, |
69 |
but most GitHub project Wikis may be small. |
70 |
|
71 |
> 1b. What possible future use it could have. |
72 |
> |
73 |
|
74 |
It could maintain all public facing documents. |
75 |
|
76 |
> 1c. How much effort will the future maintenance take. |
77 |
> |
78 |
|
79 |
I do not see how it would take more maintenance time than Jekyll. It |
80 |
may take less as it offers Wiki specific features. |
81 |
|
82 |
> 2. A publicly available working instance that resembles the workflow |
83 |
> we're aiming for, or an easy way of setting one up. Easy = ~5 simple |
84 |
> shell commands, not 'set a webserver up'. |
85 |
> |
86 |
|
87 |
The README offers concise instructions for setting up a demonstration |
88 |
instance and scaling up. Should that be hard to read, a video is |
89 |
available (https://www.youtube.com/watch?v=EauxgxsLDC4). |
90 |
|
91 |
> 3. A statement from an Infra member that is willing to set the instance |
92 |
> up and maintain it. |
93 |
> |
94 |
|
95 |
It seems like it is your burden to interpret the suggestion and refer |
96 |
it to the people who would be maintaining it. If you don't want to |
97 |
then that is fine. |
98 |
|
99 |
> Because otherwise we're only going to lose time on theoretical debates |
100 |
> over software without even knowing if it will work at all, do what it's |
101 |
> supposed to do, and most importantly, if someone will actually set |
102 |
> a production instance up and maintain it afterwards. |
103 |
> |
104 |
|
105 |
It is not possible for me to know everything you would like addressed |
106 |
in advance. |
107 |
|
108 |
Most of the problems Gentoo faces are unique enough that I do not |
109 |
think it is reasonable to expect a useful solution to exist. There |
110 |
will always be problems. |
111 |
|
112 |
> Infra already maintains enough diverse platforms/services/frameworks |
113 |
> that serve only a single tool selected by one person who used to like |
114 |
> it, and not maintained anymore. SMW belongs to that group. |
115 |
> |
116 |
>> It would not require pages be rewritten and can render |
117 |
>> MediaWiki that is maintained in a Git repository. |
118 |
> |
119 |
> Secondly, even if Gollum supported MW markup to the point of rendering |
120 |
> GLEPs (which it doesn't [1]), MW markup is not suitable for any |
121 |
> technical specifications or serious documentation for two reasons: |
122 |
> |
123 |
> a. MW markup is not proper WYWIWYG. Any more complex part of |
124 |
> the document is not readable as plaintext. Add to that the horrible |
125 |
> syntax requiring <nowiki> use mixed with inline HTML... |
126 |
> |
127 |
> b. MW markup is not standalone. Our GLEPs already started heavily |
128 |
> depending on random templates (which can change at any time, breaking |
129 |
> GLEPs in the process btw). |
130 |
> |
131 |
|
132 |
Yes, I suppose the lack of templates might make it unusable. |
133 |
|
134 |
I never meant to defend MW. It just might have been possible to avoid |
135 |
rewriting many of the pages until absolutely necessary. |
136 |
|
137 |
>> It should be all of the positives with no negatives. |
138 |
> |
139 |
> Is it? |
140 |
> |
141 |
|
142 |
I don't know. You are the one with more information than me. I only |
143 |
stated as much because it genuinely seems like it is; follow up on my |
144 |
suggestion if it looks like it may initially be suitable. |
145 |
|
146 |
Even large problems like the lack of real authentication do not really |
147 |
make the situation any worse than it already is with controlled Wiki |
148 |
pages. For more restricted pages it is likely irrelevant. |
149 |
|
150 |
There was quite a bit of research involved in my original suggestion |
151 |
of Gollum, however I didn't think to look at some of the points you |
152 |
brought up. It looks like it might not be suitable. It also looks like |
153 |
there may not be anything "suitable," really, though static website |
154 |
generation may be the least intrusive. |
155 |
|
156 |
Respectfully, |
157 |
R0b0t1 |
158 |
|
159 |
|
160 |
[1]: https://github.com/gollum/gollum/issues/1078 |