Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Duck]

Quack,

On 06/21/2017 05:29 PM, Martin Sivak wrote:
>> I think we need a wiki for this, instead of reinventing one :-)

Well, the only feature which seem to be missing (at least for some
people) is to comment alongside the pages, but you can still make
reviews in PRs.

I think these last few month there is more people around and it is more
reactive, and there's much less lingering PRs.

Also I have no idea about how promoting people to merge power is done. I
think there is quite an unfair side of the story: if you're from RH then
you can get admin rights on the spot but external contributors I guess
don't guess this very easily. I didn't any procedure to apply for this.

> Other big ans successful [1] (single component) projects have docs/
> directory and documentation and design reviews are integral part of
> code review. That way you can atomically reject/accept changes to code
> and docs together. We can't easily do it this way as we have multiple
> cooperating components, but we should try to get close.

That's a very good point. A colleague working on OpenStack stuff was
telling me this works much better to commit doc alongside doc in the
same PR.

Also the project promotion and technical docs would probably benefit
from being separated, so that giving permissions to people would not
affect the main portal and messaging if they just need to write on
features/config/install/…

> Yes we do, but we do not have commit rights. And internal technical
> documentation and _design_ pages need to be a bit closer to the source
> otherwise nobody will want to touch them.

Same.

> And don't let me started on the theoretical open aspect of our
> project.. do we want more contributors or not? Can we afford
> artificial barriers? Is somebody from general public allowed to
> contribute ideas?

With GH and Gerrit using external auth I think anyone is able to contribute.



So to come back to Markdown stuff. People in charge of messaging do not
want an ugly portal, and even a simple one means a little bit of CSS.
Also there are news/blog entries, so another feature which needs
slightly more power. Also search is a nice feature too. So we're using
Middleman, that's not perfect at all, version 3 is a failure, and we
were looking at a new tool, Jekyll, and it's being tested on another
project.

Jekyll is the tool developed by GH and this rejoins Edward's proposal.

Nevertheless I totally disagree about going to the bare minimum. If you
want to get a clean, readable and coherent documentation you will still
end-up having a few editorial rules, templates… to follow and yes you
need to get up to it and learn. With content of this size if anyone just
decide to have his own flavor it will be a mess very soon.

Also we already have piles of content so this means some work to
migrate. Markdown is not a standard so depending on the generator you
use the syntax may differ slightly. There's some custom Ruby code we
need to get rid of too. So that's a real project and unfortunately the
person who was working in this direction is no more in the project. Once
I'm more acquainted to Jekyll and i still think this could be a nice
replacement, then I'll try to get some time to help on this front.

Anyway to get out of the current system we first need to remove all the
custom Ruby code around Middleman and maybe other ugly things, so…
patches are welcome!

\_o<



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Martin Sivak]

> I think we need a wiki for this, instead of reinventing one :-)

Really? And ending in the same mess we had before? No thanks.

Other big ans successful [1] (single component) projects have docs/
directory and documentation and design reviews are integral part of
code review. That way you can atomically reject/accept changes to code
and docs together. We can't easily do it this way as we have multiple
cooperating components, but we should try to get close.

> We have a builtin markdown based wiki in the ovirt site github project.

Yes we do, but we do not have commit rights. And internal technical
documentation and _design_ pages need to be a bit closer to the source
otherwise nobody will want to touch them.

> For discussion, we have the mailing list and other channels like bluejeans
> and irc.

For informal yes. But formal proposals and final design documentation
are something different.

And don't let me started on the theoretical open aspect of our
project.. do we want more contributors or not? Can we afford
artificial barriers? Is somebody from general public allowed to
contribute ideas?

Gerrit / Github give everybody the power to easily see all currently
considered (open) projects and review them using the same interface we
use for our daily work! This way any team can catch conceptual issues
with other teams' projects. Searching through email threads is nowhere
near the same experience.

[1] kubernetes and Linux kernel just to name two

--
Martin Sivak
SLA / oVirt


On Tue, Jun 20, 2017 at 9:22 PM, Nir Soffer  wrote:
>
> בתאריך יום ג׳, 20 ביוני 2017, 13:10, מאת Martin Sivak ‏:
>>
>> Hi,
>>
>> I think what Edy did here makes sense. We do not need anything fancy
>> for technical documentation and design. This would also be easy to
>> maintain or integrate to the main website (git submodules will help).
>>
>> I have two basic requirements for design space:
>>
>> - commenting so devs can discuss the design
>> - ease of update so we can respond to comments
>>
>> A plain markdown repo would work well for this and both points are
>> possible using github or gerrit workflows.
>>
>> I would actually prefer if we had something that is directly part of
>> the source repositories so we could review code updates and docs
>> updates together. Unfortunately that it is hard to do when we have
>> multiple different components to update. So this proposal is probably
>> the next best thing.
>
>
> I think we need a wiki for this, instead of reinventing one :-)
>
> We have a builtin markdown based wiki in the ovirt site github project.
>
> For discussion, we have the mailing list and other channels like bluejeans
> and irc.
>
> Nir
>
>>
>> --
>> Martin Sivak
>> SLA
>>
>>
>> On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
>> > Hi all,
>> >
>> > Came back to this thread due to a need to post some design
>> > documentation.
>> > After fetching the ovirt-site and looking up where to start the
>> > document, I
>> > remembered why I stopped using it.
>> >
>> > After exploring several options, including the GitHub wiki, I think that
>> > for
>> > the development documentation we can just go with the minimum:
>> > Use a repo to just post markdown and image files, letting GitHub
>> > rendering/view of such files to do the job for us.
>> > We can still review the documents and have discussions on the content,
>> > and
>> > provide access to all who wants to use it (to perform the merges).
>> > The fact it uses markdown and images, can allow its content to be
>> > relocated
>> > to any other solutions that will come later on, including adding the
>> > content
>> > back on ovirt-site.
>> >
>> > Here is a simple example:
>> > https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>> >
>> > it uses simple markdown md files with relative links to other pages.
>> > Adding
>> > images is also simple.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Edy.
>> >
>> >
>> >
>> > On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>> >  wrote:
>> >>
>> >>
>> >> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>> >>
>> >>
>> >>
>> >> On 11 January 2017 at 17:06, Marc Dequènes (Duck) 
>> >> wrote:
>> >>>
>> >>> Quack,
>> >>>
>> >>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> >>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>> >>> >> Adding infra which I forgot to add from the beginning
>> >>>
>> >>> Thanks.
>> >>>
>> >>> > I don't think this is an infra issue, more of a community/working
>> >>> > procedures one.
>> >>>
>> >>> I do thin it is. We are involved in the tooling, for their
>> >>> maintenance,
>> >>> for documenting where things are, for suggesting better solutions,
>> >>> ensuring security…
>> >>>
>> >>> > 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 

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Edward Haas]

On Tue, Jun 20, 2017 at 10:22 PM, Nir Soffer  wrote:

>
> בתאריך יום ג׳, 20 ביוני 2017, 13:10, מאת Martin Sivak ‏ >:
>
>> Hi,
>>
>> I think what Edy did here makes sense. We do not need anything fancy
>> for technical documentation and design. This would also be easy to
>> maintain or integrate to the main website (git submodules will help).
>>
>> I have two basic requirements for design space:
>>
>> - commenting so devs can discuss the design
>> - ease of update so we can respond to comments
>>
>> A plain markdown repo would work well for this and both points are
>> possible using github or gerrit workflows.
>>
>> I would actually prefer if we had something that is directly part of
>> the source repositories so we could review code updates and docs
>> updates together. Unfortunately that it is hard to do when we have
>> multiple different components to update. So this proposal is probably
>> the next best thing.
>>
>
> I think we need a wiki for this, instead of reinventing one :-)
>
> We have a builtin markdown based wiki in the ovirt site github project.
>
> For discussion, we have the mailing list and other channels like bluejeans
> and irc.
>

Discussing reviews through emails?? Good luck with that.
What's next? Sending patches through emails?

I want the power of the review (gerrit/github), not a poor alternative.
The only advantage of github over gerrit in this respect is the already
existing rendering
of the md files.


>
>
> Nir
>
>
>> --
>> Martin Sivak
>> SLA
>>
>>
>> On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
>> > Hi all,
>> >
>> > Came back to this thread due to a need to post some design
>> documentation.
>> > After fetching the ovirt-site and looking up where to start the
>> document, I
>> > remembered why I stopped using it.
>> >
>> > After exploring several options, including the GitHub wiki, I think
>> that for
>> > the development documentation we can just go with the minimum:
>> > Use a repo to just post markdown and image files, letting GitHub
>> > rendering/view of such files to do the job for us.
>> > We can still review the documents and have discussions on the content,
>> and
>> > provide access to all who wants to use it (to perform the merges).
>> > The fact it uses markdown and images, can allow its content to be
>> relocated
>> > to any other solutions that will come later on, including adding the
>> content
>> > back on ovirt-site.
>> >
>> > Here is a simple example:
>> > https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>> >
>> > it uses simple markdown md files with relative links to other pages.
>> Adding
>> > images is also simple.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Edy.
>> >
>> >
>> >
>> > On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>> >  wrote:
>> >>
>> >>
>> >> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>> >>
>> >>
>> >>
>> >> On 11 January 2017 at 17:06, Marc Dequènes (Duck) 
>> wrote:
>> >>>
>> >>> Quack,
>> >>>
>> >>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> >>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>> >>> >> Adding infra which I forgot to add from the beginning
>> >>>
>> >>> Thanks.
>> >>>
>> >>> > I don't think this is an infra issue, more of a community/working
>> >>> > procedures one.
>> >>>
>> >>> I do thin it is. We are involved in the tooling, for their
>> maintenance,
>> >>> for documenting where things are, for suggesting better solutions,
>> >>> ensuring security…
>> >>>
>> >>> > 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.
>> >>>
>> >>> 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.
>> >>
>> >>
>> >> 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.
>> >> 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
>> >>
>> >>>
>> >>> For people with few git knowledge, the GitHub web interface allows to
>> >>> edit files.
>> >>>
>> >>> > On the other hand, the user community needs a good, up to date
>> source
>> >>> > of information about oVirt and how to use it.
>> >>>
>> >>> Yes, this official entry point and it needs to be clean.
>> >>
>> >>
>> >> yep, you’re 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 

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Nir Soffer]

בתאריך יום ג׳, 20 ביוני 2017, 13:10, מאת Martin Sivak ‏:

> Hi,
>
> I think what Edy did here makes sense. We do not need anything fancy
> for technical documentation and design. This would also be easy to
> maintain or integrate to the main website (git submodules will help).
>
> I have two basic requirements for design space:
>
> - commenting so devs can discuss the design
> - ease of update so we can respond to comments
>
> A plain markdown repo would work well for this and both points are
> possible using github or gerrit workflows.
>
> I would actually prefer if we had something that is directly part of
> the source repositories so we could review code updates and docs
> updates together. Unfortunately that it is hard to do when we have
> multiple different components to update. So this proposal is probably
> the next best thing.
>

I think we need a wiki for this, instead of reinventing one :-)

We have a builtin markdown based wiki in the ovirt site github project.

For discussion, we have the mailing list and other channels like bluejeans
and irc.

Nir


> --
> Martin Sivak
> SLA
>
>
> On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
> > Hi all,
> >
> > Came back to this thread due to a need to post some design documentation.
> > After fetching the ovirt-site and looking up where to start the
> document, I
> > remembered why I stopped using it.
> >
> > After exploring several options, including the GitHub wiki, I think that
> for
> > the development documentation we can just go with the minimum:
> > Use a repo to just post markdown and image files, letting GitHub
> > rendering/view of such files to do the job for us.
> > We can still review the documents and have discussions on the content,
> and
> > provide access to all who wants to use it (to perform the merges).
> > The fact it uses markdown and images, can allow its content to be
> relocated
> > to any other solutions that will come later on, including adding the
> content
> > back on ovirt-site.
> >
> > Here is a simple example:
> > https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
> >
> > it uses simple markdown md files with relative links to other pages.
> Adding
> > images is also simple.
> >
> > What do you think?
> >
> > Thanks,
> > Edy.
> >
> >
> >
> > On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
> >  wrote:
> >>
> >>
> >> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
> >>
> >>
> >>
> >> On 11 January 2017 at 17:06, Marc Dequènes (Duck) 
> wrote:
> >>>
> >>> Quack,
> >>>
> >>> On 01/08/2017 06:39 PM, Barak Korren wrote:
> >>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
> >>> >> Adding infra which I forgot to add from the beginning
> >>>
> >>> Thanks.
> >>>
> >>> > I don't think this is an infra issue, more of a community/working
> >>> > procedures one.
> >>>
> >>> I do thin it is. We are involved in the tooling, for their maintenance,
> >>> for documenting where things are, for suggesting better solutions,
> >>> ensuring security…
> >>>
> >>> > 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.
> >>>
> >>> 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.
> >>
> >>
> >> 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.
> >> 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
> >>
> >>>
> >>> For people with few git knowledge, the GitHub web interface allows to
> >>> edit files.
> >>>
> >>> > On the other hand, the user community needs a good, up to date source
> >>> > of information about oVirt and how to use it.
> >>>
> >>> Yes, this official entry point and it needs to be clean.
> >>
> >>
> >> yep, you’re 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
> >>>
> >>> We could indeed split the technical documentation. If people want to
> >>> experiment with the GH wiki pages, I won't interfere.
> >>>
> >>> I read several people in this thread really miss the old wiki, so I
> >>> 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 

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Martin Sivak]

Hi,

I think what Edy did here makes sense. We do not need anything fancy
for technical documentation and design. This would also be easy to
maintain or integrate to the main website (git submodules will help).

I have two basic requirements for design space:

- commenting so devs can discuss the design
- ease of update so we can respond to comments

A plain markdown repo would work well for this and both points are
possible using github or gerrit workflows.

I would actually prefer if we had something that is directly part of
the source repositories so we could review code updates and docs
updates together. Unfortunately that it is hard to do when we have
multiple different components to update. So this proposal is probably
the next best thing.

--
Martin Sivak
SLA


On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
> Hi all,
>
> Came back to this thread due to a need to post some design documentation.
> After fetching the ovirt-site and looking up where to start the document, I
> remembered why I stopped using it.
>
> After exploring several options, including the GitHub wiki, I think that for
> the development documentation we can just go with the minimum:
> Use a repo to just post markdown and image files, letting GitHub
> rendering/view of such files to do the job for us.
> We can still review the documents and have discussions on the content, and
> provide access to all who wants to use it (to perform the merges).
> The fact it uses markdown and images, can allow its content to be relocated
> to any other solutions that will come later on, including adding the content
> back on ovirt-site.
>
> Here is a simple example:
> https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>
> it uses simple markdown md files with relative links to other pages. Adding
> images is also simple.
>
> What do you think?
>
> Thanks,
> Edy.
>
>
>
> On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>  wrote:
>>
>>
>> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>>
>>
>>
>> On 11 January 2017 at 17:06, Marc Dequènes (Duck)  wrote:
>>>
>>> Quack,
>>>
>>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>>> >> Adding infra which I forgot to add from the beginning
>>>
>>> Thanks.
>>>
>>> > I don't think this is an infra issue, more of a community/working
>>> > procedures one.
>>>
>>> I do thin it is. We are involved in the tooling, for their maintenance,
>>> for documenting where things are, for suggesting better solutions,
>>> ensuring security…
>>>
>>> > 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.
>>>
>>> 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.
>>
>>
>> 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.
>> 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
>>
>>>
>>> For people with few git knowledge, the GitHub web interface allows to
>>> edit files.
>>>
>>> > On the other hand, the user community needs a good, up to date source
>>> > of information about oVirt and how to use it.
>>>
>>> Yes, this official entry point and it needs to be clean.
>>
>>
>> yep, you’re 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
>>>
>>> We could indeed split the technical documentation. If people want to
>>> experiment with the GH wiki pages, I won't interfere.
>>>
>>> I read several people in this thread really miss the old wiki, so I
>>> 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… 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.
>>
>>
>> it was also a bit difficult to edit, plus a barrier 

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Edward Haas]

Hi all,

Came back to this thread due to a need to post some design documentation.
After fetching the ovirt-site and looking up where to start the document, I
remembered why I stopped using it.

After exploring several options, including the GitHub wiki, I think that
for the development documentation we can just go with the minimum:
Use a repo to just post markdown and image files, letting GitHub
rendering/view of such files to do the job for us.
We can still review the documents and have discussions on the content, and
provide access to all who wants to use it (to perform the merges).
The fact it uses markdown and images, can allow its content to be relocated
to any other solutions that will come later on, including adding the
content back on ovirt-site.

Here is a simple example:
https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md

it uses simple markdown md files with relative links to other pages. Adding
images is also simple.

What do you think?

Thanks,
Edy.



On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>
>
>
> On 11 January 2017 at 17:06, Marc Dequènes (Duck)  wrote:
>
>> Quack,
>>
>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>> >> Adding infra which I forgot to add from the beginning
>>
>> Thanks.
>>
>> > I don't think this is an infra issue, more of a community/working
>> > procedures one.
>>
>> I do thin it is. We are involved in the tooling, for their maintenance,
>> for documenting where things are, for suggesting better solutions,
>> ensuring security…
>>
>> > 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.
>>
>> 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.
>>
>
> 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.
> 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
>
>
>> For people with few git knowledge, the GitHub web interface allows to
>> edit files.
>>
>> > On the other hand, the user community needs a good, up to date source
>> > of information about oVirt and how to use it.
>>
>> Yes, this official entry point and it needs to be clean.
>>
>
> yep, you’re 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
>>
>> We could indeed split the technical documentation. If people want to
>> experiment with the GH wiki pages, I won't interfere.
>>
>> I read several people in this thread really miss the old wiki, so I
>> 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… 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.
>>
>
> it was also a bit difficult to edit, plus a barrier of ~1 month it took to
> get an account
>
>
>> 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.
>>
>> 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.
>>
>> So to sum up:
>>   - the most needed thing here is not a tool but people in charge to
>> review the content 

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Michal Skrivanek]

> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
> 
> 
> 
> On 11 January 2017 at 17:06, Marc Dequènes (Duck)  > wrote:
> Quack,
> 
> On 01/08/2017 06:39 PM, Barak Korren wrote:
> > On 8 January 2017 at 10:17, Roy Golan  > > wrote:
> >> Adding infra which I forgot to add from the beginning
> 
> Thanks.
> 
> > I don't think this is an infra issue, more of a community/working
> > procedures one.
> 
> I do thin it is. We are involved in the tooling, for their maintenance,
> for documenting where things are, for suggesting better solutions,
> ensuring security…
> 
> > 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.
> 
> 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.

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. 
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

> 
> For people with few git knowledge, the GitHub web interface allows to
> edit files.
> 
> > On the other hand, the user community needs a good, up to date source
> > of information about oVirt and how to use it.
> 
> Yes, this official entry point and it needs to be clean.

yep, you’re 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
> 
> We could indeed split the technical documentation. If people want to
> experiment with the GH wiki pages, I won't interfere.
> 
> I read several people in this thread really miss the old wiki, so I
> 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… 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.

it was also a bit difficult to edit, plus a barrier of ~1 month it took to get 
an account

> 
> 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.
> 
> 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.
> 
> 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…), this should also allow for faster 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

> 
> \_o<
> 
> 
> 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.  

thanks roy for bringing it up

Thanks,
michal

> 
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Users mailing list
Users@ovirt.org

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Roy Golan]

On 11 January 2017 at 17:06, Marc Dequènes (Duck)  wrote:

> Quack,
>
> On 01/08/2017 06:39 PM, Barak Korren wrote:
> > On 8 January 2017 at 10:17, Roy Golan  wrote:
> >> Adding infra which I forgot to add from the beginning
>
> Thanks.
>
> > I don't think this is an infra issue, more of a community/working
> > procedures one.
>
> I do thin it is. We are involved in the tooling, for their maintenance,
> for documenting where things are, for suggesting better solutions,
> ensuring security…
>
> > 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.
>
> 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.
>
> For people with few git knowledge, the GitHub web interface allows to
> edit files.
>
> > On the other hand, the user community needs a good, up to date source
> > of information about oVirt and how to use it.
>
> Yes, this official entry point and it needs to be clean.
>
> > 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
>
> We could indeed split the technical documentation. If people want to
> experiment with the GH wiki pages, I won't interfere.
>
> I read several people in this thread really miss the old wiki, so I
> 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… 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.
>
> 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.
>
> 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.
>
> 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…), this should also allow for faster 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
>
> \_o<
>
>
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.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Duck]

Quack,

On 01/08/2017 06:39 PM, Barak Korren wrote:
> On 8 January 2017 at 10:17, Roy Golan  wrote:
>> Adding infra which I forgot to add from the beginning

Thanks.

> I don't think this is an infra issue, more of a community/working
> procedures one.

I do thin it is. We are involved in the tooling, for their maintenance,
for documenting where things are, for suggesting better solutions,
ensuring security…

> 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.

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.

For people with few git knowledge, the GitHub web interface allows to
edit files.

> On the other hand, the user community needs a good, up to date source
> of information about oVirt and how to use it. 

Yes, this official entry point and it needs to be clean.

> 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

We could indeed split the technical documentation. If people want to
experiment with the GH wiki pages, I won't interfere.

I read several people in this thread really miss the old wiki, so I
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… 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.

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.

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.

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…), this should also allow for faster 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

\_o<



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Barak Korren]

On 8 January 2017 at 10:17, Roy Golan  wrote:
> Adding infra which I forgot to add from the beginning

I don't think this is an infra issue, more of a community/working
procedures one.

I'm going to state my view on this, the same one I've stated before,
with hopes of reaching a conclusion that will be beneficial to
everyone.

The core of the issue here is that we have two conflicting needs.

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.

On the other hand, the user community needs a good, up to date source
of information about oVirt and how to use it. To keep the information
quality high, there is a need for some editorial process. The OSAS
team stepped in to offer editorial services and is doing tremendous
work behind the scenes. This creates the desire to use the same tools
and flows that OSAS is using for other projects.

One thing that I don't thing is a hard requirement, is to have the
design documents on the main oVirt website. In fact, I think that the
(Typically outdated) design documents being stored on the main site,
and linked to as "features" had been a major source of confusion for
users.

This all leads me to the conclusion that the currently offered
solution, of using the GitHub project wiki feature may indeed be the
appropriate solution for this (Even though I personally resent the
growing dependency of open source projects on proprietary
closed-source online platforms).

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 (I've enabled the wiki for engine [1] and vdsm [2] for
example). For system-wide features, I suppose OST [2] will be
appropriate, with hopes that this will provide some incentive to write
tests for those features.

[1]: https://github.com/oVirt/ovirt-engine/wiki
[2]: https://github.com/oVirt/vdsm/wiki
[3]: https://github.com/oVirt/ovirt-system-tests/wiki

-- 
Barak Korren
bkor...@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Roy Golan]

Adding infra which I forgot to add from the beginning

On 7 January 2017 at 02:44, Jakub Niedermertl  wrote:

> On Wed, Jan 4, 2017 at 11:41 AM, Roy Golan  wrote:
> >
> >
> > On 4 January 2017 at 12:17, Maor Lipchuk  wrote:
> >>
> >>
> >>
> >> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:
> 
>  I'm getting the feeling I'm not alone in this, authoring and
> publishing
>  a wiki page isn't as used to be for long time.
> 
>  I want to suggest a bit lighter workflow:
> 
>  1.  Everyone can merge their page - (it's a wiki)
>    Same as with (public and open) code, no one has the motivation to
>  publish a badly written
>    wiki page under their name. True, it can have an impact, but not as
>  with broken code
> 
> >>>
> >>> +1.
> >>> Moreover, I think we shouldn't block any merging. Instead, wiki
> >>> maintainers could act afterwards and revert when needed (Wikipedia
> style).
> >>> Another issue is that (sadly) unlike mediawiki, we need to wait for
> wiki
> >>> publish after a change. So I'd suggest to build and publish the wiki at
> >>> least once a day. Any way, I think we should make the workflow much
> more
> >>> intuitive and pleasant like the previous wiki - i.e. much less
> restrictive
> >>> than manipulating a code base.
> >>>
> >>>
> 
>  2. Use Page-Status marker
>   The author first merges the draft. Its now out there and should be
>  updated as time goes and its
>   status is DRAFT. Maintainers will come later and after review would
>  change the status to
>   PUBLISH. That could be a header in on the page:
>   ---
>   page status: DRAFT/PUBLISH
>   ---
> 
>   Simple I think, and should work.
> 
> >>
> >>  +1
> >> The effort of maintaining the wiki today compare to how it used to be
> >> before is much more cumbersome and problematic.
> >> I think we can learn a lot from wikipedia workflow,
> >> It is a much more inviting process where anyone can change the content
> >> easily.
> >> I'm not saying we should let any anonymous user change the wiki but even
> >> if we make it easier in house we can achieve much more informative
> reliable
> >> and updated wiki.
> >>
> >
> >
> >
> > I really think Github Pages is a perfect fit and an alternative to my
> first
> > suggestion. see
> > https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F
>
> +1
> Github wiki would allow us instant publishing, review after after
> publishing, it works purely in browser (no need for running local ruby
> server) and it's a service that doesn't require any maintenance form
> our side.
>
> 
> 
> 
> 
>  ___
>  Devel mailing list
>  de...@ovirt.org
>  http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>>
> >>>
> >>> ___
> >>> Users mailing list
> >>> Users@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/users
> >>>
> >>
> >
> >
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Jakub Niedermertl]

On Wed, Jan 4, 2017 at 11:41 AM, Roy Golan  wrote:
>
>
> On 4 January 2017 at 12:17, Maor Lipchuk  wrote:
>>
>>
>>
>> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez  wrote:
>>>
>>>
>>>
>>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:

 I'm getting the feeling I'm not alone in this, authoring and publishing
 a wiki page isn't as used to be for long time.

 I want to suggest a bit lighter workflow:

 1.  Everyone can merge their page - (it's a wiki)
   Same as with (public and open) code, no one has the motivation to
 publish a badly written
   wiki page under their name. True, it can have an impact, but not as
 with broken code

>>>
>>> +1.
>>> Moreover, I think we shouldn't block any merging. Instead, wiki
>>> maintainers could act afterwards and revert when needed (Wikipedia style).
>>> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki
>>> publish after a change. So I'd suggest to build and publish the wiki at
>>> least once a day. Any way, I think we should make the workflow much more
>>> intuitive and pleasant like the previous wiki - i.e. much less restrictive
>>> than manipulating a code base.
>>>
>>>

 2. Use Page-Status marker
  The author first merges the draft. Its now out there and should be
 updated as time goes and its
  status is DRAFT. Maintainers will come later and after review would
 change the status to
  PUBLISH. That could be a header in on the page:
  ---
  page status: DRAFT/PUBLISH
  ---

  Simple I think, and should work.

>>
>>  +1
>> The effort of maintaining the wiki today compare to how it used to be
>> before is much more cumbersome and problematic.
>> I think we can learn a lot from wikipedia workflow,
>> It is a much more inviting process where anyone can change the content
>> easily.
>> I'm not saying we should let any anonymous user change the wiki but even
>> if we make it easier in house we can achieve much more informative reliable
>> and updated wiki.
>>
>
>
>
> I really think Github Pages is a perfect fit and an alternative to my first
> suggestion. see
> https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F

+1
Github wiki would allow us instant publishing, review after after
publishing, it works purely in browser (no need for running local ruby
server) and it's a service that doesn't require any maintenance form
our side.





 ___
 Devel mailing list
 de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Nir Soffer]

On Wed, Jan 4, 2017 at 12:41 PM, Roy Golan  wrote:
>
>
> On 4 January 2017 at 12:17, Maor Lipchuk  wrote:
>>
>>
>>
>> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez  wrote:
>>>
>>>
>>>
>>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:

 I'm getting the feeling I'm not alone in this, authoring and publishing
 a wiki page isn't as used to be for long time.

 I want to suggest a bit lighter workflow:

 1.  Everyone can merge their page - (it's a wiki)
   Same as with (public and open) code, no one has the motivation to
 publish a badly written
   wiki page under their name. True, it can have an impact, but not as
 with broken code

>>>
>>> +1.
>>> Moreover, I think we shouldn't block any merging. Instead, wiki
>>> maintainers could act afterwards and revert when needed (Wikipedia style).
>>> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki
>>> publish after a change. So I'd suggest to build and publish the wiki at
>>> least once a day. Any way, I think we should make the workflow much more
>>> intuitive and pleasant like the previous wiki - i.e. much less restrictive
>>> than manipulating a code base.
>>>
>>>

 2. Use Page-Status marker
  The author first merges the draft. Its now out there and should be
 updated as time goes and its
  status is DRAFT. Maintainers will come later and after review would
 change the status to
  PUBLISH. That could be a header in on the page:
  ---
  page status: DRAFT/PUBLISH
  ---

  Simple I think, and should work.

>>
>>  +1
>> The effort of maintaining the wiki today compare to how it used to be
>> before is much more cumbersome and problematic.
>> I think we can learn a lot from wikipedia workflow,
>> It is a much more inviting process where anyone can change the content
>> easily.
>> I'm not saying we should let any anonymous user change the wiki but even
>> if we make it easier in house we can achieve much more informative reliable
>> and updated wiki.
>>
>
>
>
> I really think Github Pages is a perfect fit and an alternative to my first
> suggestion. see
> https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F

This is not github pages, this is the builtin wiki, but we can use this for
developing content.





 ___
 Devel mailing list
 de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Roy Golan]

On 4 January 2017 at 12:17, Maor Lipchuk  wrote:

>
>
> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez  wrote:
>
>>
>>
>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:
>>
>>> I'm getting the feeling I'm not alone in this, authoring and publishing
>>> a wiki page isn't as used to be for long time.
>>>
>>> I want to suggest a bit lighter workflow:
>>>
>>> 1.  Everyone can merge their page - (it's a wiki)
>>>   Same as with (public and open) code, no one has the motivation to
>>> publish a badly written
>>>   wiki page under their name. True, it can have an impact, but not as
>>> with broken code
>>>
>>>
>> +1.
>> Moreover, I think we shouldn't block any merging. Instead, wiki
>> maintainers could act afterwards and revert when needed (Wikipedia style).
>> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki
>> publish after a change. So I'd suggest to build and publish the wiki at
>> least once a day. Any way, I think we should make the workflow much more
>> intuitive and pleasant like the previous wiki - i.e. much less restrictive
>> than manipulating a code base.
>>
>
>>
>>> 2. Use Page-Status marker
>>>  The author first merges the draft. Its now out there and should be
>>> updated as time goes and its
>>>  status is DRAFT. Maintainers will come later and after review would
>>> change the status to
>>>  PUBLISH. That could be a header in on the page:
>>>  ---
>>>  page status: DRAFT/PUBLISH
>>>  ---
>>>
>>>  Simple I think, and should work.
>>>
>>>
>  +1
> The effort of maintaining the wiki today compare to how it used to be
> before is much more cumbersome and problematic.
> I think we can learn a lot from wikipedia workflow,
> It is a much more inviting process where anyone can change the content
> easily.
> I'm not saying we should let any anonymous user change the wiki but even
> if we make it easier in house we can achieve much more informative reliable
> and updated wiki.
>
>


I really think Github Pages is a perfect fit and an alternative to my first
suggestion. see
https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F

>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> de...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Maor Lipchuk]

On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez  wrote:

>
>
> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:
>
>> I'm getting the feeling I'm not alone in this, authoring and publishing a
>> wiki page isn't as used to be for long time.
>>
>> I want to suggest a bit lighter workflow:
>>
>> 1.  Everyone can merge their page - (it's a wiki)
>>   Same as with (public and open) code, no one has the motivation to
>> publish a badly written
>>   wiki page under their name. True, it can have an impact, but not as
>> with broken code
>>
>>
> +1.
> Moreover, I think we shouldn't block any merging. Instead, wiki
> maintainers could act afterwards and revert when needed (Wikipedia style).
> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki
> publish after a change. So I'd suggest to build and publish the wiki at
> least once a day. Any way, I think we should make the workflow much more
> intuitive and pleasant like the previous wiki - i.e. much less restrictive
> than manipulating a code base.
>

>
>> 2. Use Page-Status marker
>>  The author first merges the draft. Its now out there and should be
>> updated as time goes and its
>>  status is DRAFT. Maintainers will come later and after review would
>> change the status to
>>  PUBLISH. That could be a header in on the page:
>>  ---
>>  page status: DRAFT/PUBLISH
>>  ---
>>
>>  Simple I think, and should work.
>>
>>
 +1
The effort of maintaining the wiki today compare to how it used to be
before is much more cumbersome and problematic.
I think we can learn a lot from wikipedia workflow,
It is a much more inviting process where anyone can change the content
easily.
I'm not saying we should let any anonymous user change the wiki but even if
we make it easier in house we can achieve much more informative reliable
and updated wiki.


>
>>
>>
>> ___
>> Devel mailing list
>> de...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Daniel Erez]

On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:

> I'm getting the feeling I'm not alone in this, authoring and publishing a
> wiki page isn't as used to be for long time.
>
> I want to suggest a bit lighter workflow:
>
> 1.  Everyone can merge their page - (it's a wiki)
>   Same as with (public and open) code, no one has the motivation to
> publish a badly written
>   wiki page under their name. True, it can have an impact, but not as with
> broken code
>
> +1.
Moreover, I think we shouldn't block any merging. Instead, wiki maintainers
could act afterwards and revert when needed (Wikipedia style). Another
issue is that (sadly) unlike mediawiki, we need to wait for wiki publish
after a change. So I'd suggest to build and publish the wiki at least once
a day. Any way, I think we should make the workflow much more intuitive and
pleasant like the previous wiki - i.e. much less restrictive than
manipulating a code base.


> 2. Use Page-Status marker
>  The author first merges the draft. Its now out there and should be
> updated as time goes and its
>  status is DRAFT. Maintainers will come later and after review would
> change the status to
>  PUBLISH. That could be a header in on the page:
>  ---
>  page status: DRAFT/PUBLISH
>  ---
>
>  Simple I think, and should work.
>
>
>
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Roy Golan]

On 4 January 2017 at 11:06, Nir Soffer  wrote:

> On Wed, Jan 4, 2017 at 10:51 AM, Barak Korren  wrote:
> > On 4 January 2017 at 09:57, Roy Golan  wrote:
> >> I'm getting the feeling I'm not alone in this, authoring and publishing
> a
> >> wiki page isn't as used to be for long time.
> >
> > Maybe we're using the wrong tool for the job?
> > The site is intentionally not a wiki to allow OSAS some editorial
> > control over what goes on the public site.
> >
> > I'm guessing that the scenario you are talking about here is a
> > developer looking to create a preliminary design document for further
> > discussion. Maybe we need a different tool and process for that?
>
> I agree, we are using the wrong tool for the job of putting initial design
> for discussion.
>
> For publishing user documentation the site is ok.
>
> I miss the wiki we had, it was easier to use for development of feature
> pages and developer documentation.
>


Who is our OSAS contact these days?



> Nir
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Nir Soffer]

On Wed, Jan 4, 2017 at 10:51 AM, Barak Korren  wrote:
> On 4 January 2017 at 09:57, Roy Golan  wrote:
>> I'm getting the feeling I'm not alone in this, authoring and publishing a
>> wiki page isn't as used to be for long time.
>
> Maybe we're using the wrong tool for the job?
> The site is intentionally not a wiki to allow OSAS some editorial
> control over what goes on the public site.
>
> I'm guessing that the scenario you are talking about here is a
> developer looking to create a preliminary design document for further
> discussion. Maybe we need a different tool and process for that?

I agree, we are using the wrong tool for the job of putting initial design
for discussion.

For publishing user documentation the site is ok.

I miss the wiki we had, it was easier to use for development of feature
pages and developer documentation.

Nir
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Barak Korren]

On 4 January 2017 at 09:57, Roy Golan  wrote:
> I'm getting the feeling I'm not alone in this, authoring and publishing a
> wiki page isn't as used to be for long time.

Maybe we're using the wrong tool for the job?
The site is intentionally not a wiki to allow OSAS some editorial
control over what goes on the public site.

I'm guessing that the scenario you are talking about here is a
developer looking to create a preliminary design document for further
discussion. Maybe we need a different tool and process for that?

-- 
Barak Korren
bkor...@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Yaniv Kaul]

On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:

> I'm getting the feeling I'm not alone in this, authoring and publishing a
> wiki page isn't as used to be for long time.
>

Indeed. Several changes in the process have made it more difficult than it
probably should be.


>
> I want to suggest a bit lighter workflow:
>
> 1.  Everyone can merge their page - (it's a wiki)
>

It's not really a wiki. Perhaps parts of the site should be?


>   Same as with (public and open) code, no one has the motivation to
> publish a badly written
>   wiki page under their name. True, it can have an impact, but not as with
> broken code
>

Does everyone have merge rights in public and open code?


>
> 2. Use Page-Status marker
>  The author first merges the draft. Its now out there and should be
> updated as time goes and its
>  status is DRAFT. Maintainers will come later and after review would
> change the status to
>  PUBLISH. That could be a header in on the page:
>  ---
>  page status: DRAFT/PUBLISH
>  ---
>

Interesting idea. How do we ensure we are not left with draft content all
over?
Y.


>
>  Simple I think, and should work.
>
>
>
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?

[Roman Mohr]

On Wed, Jan 4, 2017 at 8:57 AM, Roy Golan  wrote:

> I'm getting the feeling I'm not alone in this, authoring and publishing a
> wiki page isn't as used to be for long time.
>
> I want to suggest a bit lighter workflow:
>
> 1.  Everyone can merge their page - (it's a wiki)
>   Same as with (public and open) code, no one has the motivation to
> publish a badly written
>   wiki page under their name. True, it can have an impact, but not as with
> broken code
>
> 2. Use Page-Status marker
>  The author first merges the draft. Its now out there and should be
> updated as time goes and its
>  status is DRAFT. Maintainers will come later and after review would
> change the status to
>  PUBLISH. That could be a header in on the page:
>  ---
>  page status: DRAFT/PUBLISH
>  ---
>
>  Simple I think, and should work.
>
>
Sounds very good.

+1


>
>
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users