<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 January 2017 at 17:06, Marc Dequènes (Duck) <span dir="ltr"><<a href="mailto:duck@redhat.com" target="_blank">duck@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quack,<br>
<span class=""><br>
On 01/08/2017 06:39 PM, Barak Korren wrote:<br>
> On 8 January 2017 at 10:17, Roy Golan <<a href="mailto:rgolan@redhat.com">rgolan@redhat.com</a>> wrote:<br>
>> Adding infra which I forgot to add from the beginning<br>
<br>
</span>Thanks.<br>
<span class=""><br>
> I don't think this is an infra issue, more of a community/working<br>
> procedures one.<br>
<br>
</span>I do thin it is. We are involved in the tooling, for their maintenance,<br>
for documenting where things are, for suggesting better solutions,<br>
ensuring security…<br>
<span class=""><br>
> On the one hand, the developers need a place where they create and<br>
> discuss design documents and road maps. That please needs to be as<br>
> friction-free as possible to allow developers to work on the code<br>
> instead of on the documentation tools.<br>
<br>
</span>As for code, I think there is need for review, even more for design<br>
documents, so I don't see why people are bothered by PRs, which is a<br>
tool they already know fairly well.<br>
<br>
For people with few git knowledge, the GitHub web interface allows to<br>
edit files.<br>
<span class=""><br>
> On the other hand, the user community needs a good, up to date source<br>
> of information about oVirt and how to use it.<br>
<br>
</span>Yes, this official entry point and it needs to be clean.<br>
<span class=""><br>
> Having said the above, I don't think the site project's wiki is the<br>
> best place for this. The individual project mirrors on GitHub may be<br>
> better for this<br>
<br>
</span>We could indeed split the technical documentation. If people want to<br>
experiment with the GH wiki pages, I won't interfere.<br>
<br>
I read several people in this thread really miss the old wiki, so I<br>
think it is time to remember why we did not stay in paradise. I was not<br>
there at the time, but I know the wiki was not well maintained. People<br>
are comparing our situation to the MediaWiki site, but the workforce is<br>
nowhere to be compared. There is already no community manager, and noone<br>
is in charge of any part really, whereas Mediawiki has people in charge<br>
of every corner of the wiki. Also they developed tools over years to<br>
monitor, correct, revert… and we don't have any of this. So without any<br>
process then it was a total mess. More than one year later there was<br>
still much cleanup to do, and having contributed to it a little bit, I<br>
fear a sentimental rush to go back to a solution that was abandoned.<br>
<br>
Having a header telling if this is a draft or published is far from<br>
being sufficient. If noone cares you just pile up content that gets<br>
obsolete, then useless, then misleading for newcomers. You may prefer<br>
review a posteriori, but in this case you need to have the proper tool<br>
to be able to search for things to be reviewed, and a in-content<br>
pseudo-header is really not an easy way to get a todolist.<br>
<br>
As for the current builder, it checks every minute for new content to<br>
build. The current tool (Middleman) is a bit slow, and the machine is<br>
not ultra speedy, but even in the worst case it should not take more<br>
than half an hour to see the published result. So I don't know why<br>
someone suggested to build "at least once a day". There is also an<br>
experimentation to improve this part.<br>
<br>
So to sum up:<br>
- the most needed thing here is not a tool but people in charge to<br>
review the content (additions, cleanup old things, ask devs to update<br>
some missing part…), this should also allow for faster publishing<br>
- I'm not against changing tool, just do not forget what you loose in<br>
the process, and the migration pain<br>
- I think free editing without workflow in our specific case is not<br>
gonna work because we do not have the needed workforce for things to<br>
auto-correct<br>
<br>
\_o<<br>
<br></blockquote><div><br></div><div>What do you suggest then? how can infra help with this now? fwiw I don't<br></div><div>care only about 'developers', I do want to process to be better. <br></div></div><br></div></div>