This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mf2CRNBB5HrIBekLkGCVl7fFA28A9J5x4 Content-Type: multipart/mixed; boundary="KLQQcoDbkQBSA3JhvJxcIEH58dqc2asks"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck@redhat.com> To: oVirt Infra <infra@ovirt.org> Cc: Brian Proffitt <bproffit@redhat.com>, Garrett LeSage <garrett@redhat.com>, Michael Scherer <misc@redhat.com> Message-ID: <70270534-4d06-ef32-0a72-b457c96678fe@redhat.com> Subject: Future of the oVirt website --KLQQcoDbkQBSA3JhvJxcIEH58dqc2asks Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. 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. 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. 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?= 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. So this was to gather all related parties. \_o< --KLQQcoDbkQBSA3JhvJxcIEH58dqc2asks-- --Mf2CRNBB5HrIBekLkGCVl7fFA28A9J5x4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlhvJ5cACgkQVen596wc RD8Ecw//WfXl6FgFg+7R8u84dAhiDiciE/ybTPZDPWldnClTE/+L0toNSiNNBXNd 13HQGnpXpxeCH0JqdzYw0GbJB9DqRhfZBEgw55/BtPG9kPL14bTZrLlZNhvQa8p7 A+i+zAq9I6TbHeR1bY/lNf1cBZYGFRacxihlF6W62lq0jZthV2q3bRX4Fy18yWUD CmwKVKchaGrx4J0SOQ2NO4lh7enwaKpGOTzTsIlIjA+jSSKZAJt2jbKzel+bOfY/ SFDxfp2L539A4pXPDOJ4oRI4fMOZ+aVYpfGT2p+QmwMzaEu1KR4ZF0rXNDNr9SaI M//R3174Rr42oXfWpPJO1jAWeZpdGvJbVypxVFNNxFDFATrG7/JuAkoUJWbYQ28Q DKmHH8DXzyaB+NGA3rLpiAJSy59yNN5YZi/vK5I1fdF2L6uMw9dY3AND+RYSdzFp AXMx7Wg1n8MylxKc45GS6NgzCG1P43BeB0dSsLoxKZMkg7EDjwm7qug6PrebtbI8 Tvk0UEhdzHlXaGFTUrNVW6XrMJG6J9UhmoO2uS/KMUCnG2FsMJSwLPIdigxKqDSu bccFD6tQz4+VkG9KdiEw+/ofXtS5zF9ZiTPf3cETDbcMWQ8Vm47aq49sTOGF6LTt MLtPRRvu32oDg4UN6o1hGhUoiFcF8d2SEIPkDWsKahutOaL4vHw= =uxHW -----END PGP SIGNATURE----- --Mf2CRNBB5HrIBekLkGCVl7fFA28A9J5x4--
On 6 January 2017 at 07:13, Marc Dequènes (Duck) <duck@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@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 6 January 2017 at 17:26, Barak Korren <bkorren@redhat.com> wrote:
On 6 January 2017 at 07:13, Marc Dequènes (Duck) <duck@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.
This comment is not very respectful to those that written very good pages. Lets agree that the is variance in the quality of pages and there are lots of pages out there that helped numerous times.
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.
That's simplifying the topic a bit. W
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.
Wrong again - the thread is on wiki contribution and most of the developers understand the impact of publishing and discussing their work outside the VCS itself. This is not only about feature pages (which serve as the base for documentation), but yes most of the rant is about making this easier. I and I'm sure others would like to contribute how-to's, blog posts, and feature pages. Now we have few problems with what we have today: - wrong maintaners - The maintainers can't be infra as they are not familiar with the source of the information. Spelling and linting can be automated. - takes time - few maintainers, tons of content - lack of standards - too much badly written, overdue info etc... - lack of direct feedback on the content - no comment section, no revision set for pages after some time - technically a pain, to build the site locally instead of WYSIWYG All of the above makes the contribution barrier high. With that being said, we should probably arrange a cleanup hackaton to remove, update all the pages. Mark please share what is the future of ovirt site and what can be done to address the issues above mentioned.
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@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
All of the above makes the contribution barrier high. With that being said, we should probably arrange a cleanup hackaton to remove, update all the pages.
Lets not create parallel threads, please keep discussion on the main thread in devel. Having contributed a blog post the the main site, I don`t find the barrier to be as high as you say it is (I did it without even cloning the repo). But again, lets discuss this in the main thread, not here. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
participants (3)
-
Barak Korren -
Marc Dequènes (Duck) -
Roy Golan