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