Hi Allan,

Thanks a lot for your feedback, disagreement is the best to reach an agreement 
=)

---------------------------------------- This is not important

I don't feel jhbuidl to me in practice very different. We do the same with git. 
What I want is creating an
assistant (like a GtkAssistant, only one direction) which explains the firsts 
steps using whatever is necessary.
Your proposal here is: when the jhbuild part arrives, link to another page. 
That was my intention
previously as well, but that changed when the topic proposal came to my mind.

Instead of linking for every tool manual, create a single page with whatever is 
necessary, not focusing in the actual tools.
This is what https://wiki.gnome.org/GnomeLove/BuildGnome currently does.

When we were discussing about adding a "Getting started" in jhbuild 
*completely* equal to BuildGnome jhbuild part, these problems arise in my mind:
- That "getting started" is for just contributing to Gnome? Can we make others 
assumptions as well? Jhbuild still
is a generic tool. If we do this (and whatever we do with GnomeLove we still 
want this), I see the Ryan Lortie guide (HowDoI/Jhbuild) a better fit here.
- So at the end of the guide, we link to contribute with patches 
https://wiki.gnome.org/GnomeLove/CodeContributionWorkflow?? Seems unrelated.
- So they go back and forward instead of remaining in the same page?

But to be honest, I don't mind doing it like what you want. It's not even a 
concern for me right now.

------------------------------------------ This is important =)

So your assumption is right, moving most of the material of GnomeLove.

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

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.

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.

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? 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 =)

What does "bus factor 1" mean?

Cheers,
Carlos Soriano
_______________________________________________
gnome-doc-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-doc-list

Reply via email to