Re: Proposal to make GnomeLove official and move it to developer.gnome.org
- From: Allan Day <allanpday gmail com>
- To: Carlos Soriano Sanchez <csoriano redhat com>
- Cc: Magdalen Berns <m berns thismagpie com>, desktop-devel-list <desktop-devel-list gnome org>, gnome-doc-list <gnome-doc-list gnome org>
- Subject: Re: Proposal to make GnomeLove official and move it to developer.gnome.org
- Date: Fri, 20 Mar 2015 18:31:50 +0000
Carlos Soriano Sanchez <csoriano redhat com> wrote:
...
I understand what you mean with removing "community maintained", but can be misleading for others. Let me
explain:
developer.gnome.org is still maintained by the community, but they go through a review process, and gives
control to the maintainers.
Like any project we have in git.
I agree is not that easy to edit, and that can to remove some "quick edit" from community.
I think it's pretty clear that wiki pages are more accessible to
contributors than Mallard pages stored in Git. That's why Ryan started
his HowDoI initiative, and why the apps website (where most of the
pages were rotting) was dropped in favour of using the wiki instead.
And it's not just about the ability to make "quick edits" - people are
more inclined to make significant contributions if there is a low
barrier to entry.
That is what we will miss. But if we make it
intelligent, the pages won't need much maintainability. Contributing to Gnome didn't changed that much in
the years I have been contributing (3).
You're assuming that the documentation you put on developer.gnome.org
will not need improvements or elaboration, and will be perfect first
time. I'm pretty sure it won't be, and getting contributions from
others is often extremely helpful (and unlikely if you go down the
Git/Mallard/developer.gnome.org road).
Why is a problem the wiki? Why we have that feeling that currently is difficult to maintain the wiki, if we
move to a website we are making even more difficult?
Seems I'm going to do just the opposite of what we want right? =)
Let me explain. For what I saw in this years, the burden of the difficulty is not in editing the wiki, but
in the variety of what we have!
And I am 100% sure about this from my POV.
I edited 5 different jhbuild pages, 2 different guides to get started, 3 guides for git... etc. and
everything is scattered.
In general I agree that reducing duplication is helpful, but I don't
see how or why your proposal is necessary to do that. People will not
suddenly ignore pages on the wiki, just because you have "official"
content on developer.gnome.org - the wiki will need to be cleaned up
whatever happens.
So imagine, I take now a OPW to clean everything of this. In one year we will have the same problem =) I
can't be bold in the wiki,
I don't feel to be bold in the wiki. A specific example (and this one is what made the topic proposal came
to my mind):
I wrote for some months BuildGnome alongside removing some guides (reaching an agreement really takes long
time) and trying to discuss everything.
I finished, and I linked BuildGnome on GnomeLove as the *official* guide.
One month after that Ryan Lortie write a full jhbuild guide in HowDoI/Jhbuild because he thought there were
no guide for jhbuild!
He is a experienced developer and couldn't notice we had 3 jhbuild guides at that point! Clearly we are
doing something wrong...
So what now? After he spent that much time writing that very well explained guide, I say to him: hey sorry,
I'm going to delete because
we already have others and in GnomeLove we already have one linked.
No, I don't feel like doing it.
We can't stop new jhbuild/git tutorials. What I think we have to do is make clear we have a official one,
and that needs review to
*create* or *modify* it. There we can be bold, because we will have the control, and we will avoid telling
people we will remove their material.
Wikis are a bit messy sometimes, but that's the price you pay for ease
of contribution (and you're not going to be able to ban people from
adding pages to the wiki, whatever happens). I wouldn't let the
experience with the JHBuild pages put you off trying to manage the
other duplicate pages, and I'd be really happy to help you with that
if you give me the links.
To finalize, can you say to me which pages need that much work from you? It was because they were
unmaintained? Or it was because all were
scattered and need a big reorder?
In the past I've done a big clean up of the GnomeLove page [1], which
was unmaintained for some time. I also authored a number of GnomeLove
subpages (such as [2, 3, 4]), largely to fill in missing guidance.
Could we getting rid of that parts that need change over the time, or write it in a way that doesn't need
to change?
I'm curious how didn't you notice the same I'm thinking. That those pages actually don't change that much,
but is actually the scattered of those
which makes it the need to change them.
If we do it intelligently, I can imagine that the need to maintain it will be almost null =)
Documentation that doesn't get updated sounds like a false goal to me.
We should aim to ensure that the GNOME Love pages are actively
maintained, and are continually being improved.
What does "bus factor 1" mean?
See http://en.wikipedia.org/wiki/Bus_factor
Allan
[1] This is what it looked like before I started work:
https://wiki.gnome.org/action/recall/GnomeLove?action=recall&rev=134
[2] https://wiki.gnome.org/GnomeLove/GeneralAdvice
[3] https://wiki.gnome.org/GnomeLove/FindingTasks
[4] https://wiki.gnome.org/GnomeLove/JhbuildIntroduction
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]