Future of the oVirt website

[Barak Korren]

On 6 January 2017 at 07:13, Marc Dequènes (Duck) <duck at redhat.com> wrote:
> Quack,
>
> So I just discovered this thread:
>   http://lists.ovirt.org/pipermail/devel/2017-January/029097.html
>
> First, it would be nice if the infra team was involved directly, because
> not everyone is also an oVirt developer (and on this list). Also there
> are already plans to improve the site system and build and this
> side-initiative feels like an unexpected and rude disruption of energy
> already invested.

We (as in I) did get involved here:
http://lists.ovirt.org/pipermail/devel/2017-January/029103.html

Its important to understand where people are coming from and what do
they really want and then come up with the proper tools and processes.

I think I agree with you that the current flow is best suited for
maintaining www.ovirt.org is a public documentation and marketing
site. What the developers are discussing is a different requirement,
that, IMO is not suited to the main public site.

The developers have a process where, when creating a new feature, they
first create a feature page on the (so called) "wiki", and then use it
in discussions about the feature.
This is useful for developers, but the end result is a mountain of
half-edited and out of date "feature pages" that provide (IMO) very
poor service to the community.

So, in summary, the current flow does not fit what the developers want
(fast, easy, editing of feature design documents), and OTOH the
documents the developers make probably do not belong on the main site
in the form they are made, and had been put there in the past just
because the main site used to be a wiki.

So, IMO, we better just let the developers vent off, most of them do
not contribute public consumable documentation anyway, and they will
probably just find another place to put the design documents and all
will be well.

> It seems people forget how things were in the past, which leads to going
> back and forth between a new solution and the previous one. People wish
> for an easy way to contribute, and this is a legitimate goal. After some
> time an easy solution make things complicated because it is such a mess
> and there is no review, so no quality checks, and people wish to have
> workflows. Then they find it to cumbersome and wish to go back to a
> marvelous past. And so on again and again.

No, you misinterpret their goals, they are not looking to contribute
to the main site, they are looking to discuss and develop new
features. That flow never belonged on the main site, and the sooner
everyone understands that the better.

> This said, this does not mean the current solution is perfect and we
> should not think about a better one, but we should recall why we
> abandoned a wiki to switch to the current solution, so we don't fall
> into the same traps.

There is no real conflict here, just a misunderstanding. The current
flow is very good for what OSAS wants to do, which is to maintain a
high-quality public website. Its just not as good for what the
developers want, which is a place to type their half-ideas into. Those
needs do not really collide, the developers just need to go somewhere
else anyway.


> What I can say on the topic is that migrating is painful, so we should
> be cautious. OSAS is not here to force a solution upon you, but the
> infra team (and the OSAS folks too), have a limited workforce to
> dedicate to this project, so let's make something realistic. Also we
> just finish another pass of cleanup of the current site, with migration
> bugs from the previous Mediawiki solution, so keep in mind it would
> probably take _years_ to really get something clean. Who's gonna do this?

No one. I don't see this discussion as a cause for migration.
The developers can keep talking, as long as none of then volunteers to
do any real work about this, there is no risk of things changing (As
you say, OSAS and the infra team has enough other work).

> I also wanted to say I totally disagree on someone's remark (somewhere
> in the thread) about doc not being as important as code. A lot of
> content is obsolete or mistaken in the current site already, and this
> means giving a very bad image of the project, raising the number of
> silly questions people come to bother you with on ML or IRC, so I think
> doc should really be taken seriously. As a user it is often I have to
> dig in the code to find undocumented features, or why a documented one
> does not work as said, and that's fu^Wutterly boring.

This is another discussion altogether, and a worthy one, oyu should
probably reply that directly (on the ML) to the developer who did that
remark, I'm sure most other developers will agree with you.


-- 
Barak Korren
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/