<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Jan 2017, at 11:13, Roy Golan &lt;<a href="mailto:rgolan@redhat.com" class="">rgolan@redhat.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 11 January 2017 at 17:06, Marc Dequènes (Duck) <span dir="ltr" class="">&lt;<a href="mailto:duck@redhat.com" target="_blank" class="">duck@redhat.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quack,<br class="">
<span class=""><br class="">
On 01/08/2017 06:39 PM, Barak Korren wrote:<br class="">
&gt; On 8 January 2017 at 10:17, Roy Golan &lt;<a href="mailto:rgolan@redhat.com" class="">rgolan@redhat.com</a>&gt; wrote:<br class="">
&gt;&gt; Adding infra which I forgot to add from the beginning<br class="">
<br class="">
</span>Thanks.<br class="">
<span class=""><br class="">
&gt; I don't think this is an infra issue, more of a community/working<br class="">
&gt; procedures one.<br class="">
<br class="">
</span>I do thin it is. We are involved in the tooling, for their maintenance,<br class="">
for documenting where things are, for suggesting better solutions,<br class="">
ensuring security…<br class="">
<span class=""><br class="">
&gt; On the one hand, the developers need a place where they create and<br class="">
&gt; discuss design documents and road maps. That please needs to be as<br class="">
&gt; friction-free as possible to allow developers to work on the code<br class="">
&gt; instead of on the documentation tools.<br class="">
<br class="">
</span>As for code, I think there is need for review, even more for design<br class="">
documents, so I don't see why people are bothered by PRs, which is a<br class="">
tool they already know fairly well.<br class=""></blockquote></div></div></div></div></blockquote><div><br class=""></div>because it takes ages to get attention and get it in, even in cases when the text/update is more of an FYI and doesn’t require feedback.&nbsp;</div><div>That leads to frustration, and that leads to loss of any motivation to contribute anything at all.</div><div>You can see people posting on their own platforms, blogs, just to run away from this one</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
For people with few git knowledge, the GitHub web interface allows to<br class="">
edit files.<br class="">
<span class=""><br class="">
&gt; On the other hand, the user community needs a good, up to date source<br class="">
&gt; of information about oVirt and how to use it.<br class="">
<br class="">
</span>Yes, this official entry point and it needs to be clean.<br class=""></blockquote></div></div></div></div></blockquote><div><br class=""></div>yep, you’re right about the entry point -like pages</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br class="">
&gt; Having said the above, I don't think the site project's wiki is the<br class="">
&gt; best place for this. The individual project mirrors on GitHub may be<br class="">
&gt; better for this<br class="">
<br class="">
</span>We could indeed split the technical documentation. If people want to<br class="">
experiment with the GH wiki pages, I won't interfere.<br class="">
<br class="">
I read several people in this thread really miss the old wiki, so I<br class="">
think it is time to remember why we did not stay in paradise. I was not<br class="">
there at the time, but I know the wiki was not well maintained. People<br class="">
are comparing our situation to the MediaWiki site, but the workforce is<br class="">
nowhere to be compared. There is already no community manager, and noone<br class="">
is in charge of any part really, whereas Mediawiki has people in charge<br class="">
of every corner of the wiki. Also they developed tools over years to<br class="">
monitor, correct, revert… and we don't have any of this. So without any<br class="">
process then it was a total mess. More than one year later there was<br class="">
still much cleanup to do, and having contributed to it a little bit, I<br class="">
fear a sentimental rush to go back to a solution that was abandoned.<br class=""></blockquote></div></div></div></div></blockquote><div><br class=""></div>it was also a bit difficult to edit, plus a barrier of ~1 month it took to get an account</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
Having a header telling if this is a draft or published is far from<br class="">
being sufficient. If noone cares you just pile up content that gets<br class="">
obsolete, then useless, then misleading for newcomers. You may prefer<br class="">
review a posteriori, but in this case you need to have the proper tool<br class="">
to be able to search for things to be reviewed, and a in-content<br class="">
pseudo-header is really not an easy way to get a todolist.<br class="">
<br class="">
As for the current builder, it checks every minute for new content to<br class="">
build. The current tool (Middleman) is a bit slow, and the machine is<br class="">
not ultra speedy, but even in the worst case it should not take more<br class="">
than half an hour to see the published result. So I don't know why<br class="">
someone suggested to build "at least once a day". There is also an<br class="">
experimentation to improve this part.<br class="">
<br class="">
So to sum up:<br class="">
&nbsp; - the most needed thing here is not a tool but people in charge to<br class="">
review the content (additions, cleanup old things, ask devs to update<br class="">
some missing part…), this should also allow for faster publishing<br class="">
&nbsp; - I'm not against changing tool, just do not forget what you loose in<br class="">
the process, and the migration pain<br class="">
&nbsp; - I think free editing without workflow in our specific case is not<br class="">
gonna work because we do not have the needed workforce for things to<br class="">
auto-correct<br class=""></blockquote></div></div></div></div></blockquote><div><br class=""></div>I do not think we absolutely have to change a tool, just the process. We do not need anything fancy, it would be enough to e.g. automatically merge anything unless -1 from anyone in 48 hours, and maybe add protection for few intro pages we do not want to let anyone touch</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
\_o&lt;<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">What do you suggest then? how can infra help with this now? fwiw I don't<br class=""></div><div class="">care only about 'developers', I do want to process to be better.&nbsp; <br class=""></div></div></div></div></div></blockquote><div><br class=""></div>thanks roy for bringing it up</div><div><br class=""></div><div>Thanks,</div><div>michal</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div></div>
_______________________________________________<br class="">Devel mailing list<br class=""><a href="mailto:Devel@ovirt.org" class="">Devel@ovirt.org</a><br class="">http://lists.ovirt.org/mailman/listinfo/devel</div></blockquote></div><br class=""></body></html>