[wanted] thoughts on repos structure

[Nick Loeve]

Sean Wheller wrote:
> 
> The most immediate problem is to facilitate translations. We currently do not 
> use the convention of placing documents into folders intended for specific 
> languages. For example, the C/ is used for English documents. I think we may 
> need to cater for this convention if we are to maintain some order to the 
> repos going forward. Do you feel we should use this method? I will tally 
> votes and if required spawn a new thread so we can discuss proposals on 
> structure.
> 
> =vote here

This is like a ballot card :)

+1+1+1 for using the gettext inspired layout. I don't have time to do 
this for the next few days, but then i was hoping to work on this (as 
well as the .pot and .po files for rosetta)

> 
> The next problem is how to manage GNOME and KDE Documents effectively? We 
> agree to do documents for Kubuntu. I would like to start with the K Quick 
> Guide. Now, as I see it, we have a few options on how to manage this.
> 
> 1. We document in the current quickguide.xml and use profiling.
> I don't think we can do this due to the fact that we have not decided whether 
> or not ubuntu-docs will be dynamic under yelp or static html under any 
> browser. Yelp does not currently support profiling, a method we would have to 
> use if we wanted to manage in this way.
> 
> 2. We document in the same folder in a file called kquickguide.xml
> This would be straight forward as we did with the gnome document. Screen capts 
> continue to be places in images/
> 
> 3. We make a more intrusive change by creating a trunk/gnome/ and trunk/kde/ 
> where we create and maintain the two desktop docs seperately. In this case 
> each would have an image/ folder so trunk/gnome/images/ and trunk/kde/images/
> I the top level libs/, common/, etc. will remain. However, the make system 
> will need splitting into two objects, one for kde and one for gnome. The root 
> makefile can still hook these make subsystems.
> 
> Do you think we should consider using one of these methods? Please vote and I 
> will spawn a thread for this topic if required.
> 

+1 option 2 or 3. Option 1 does not look like it is doable at this point 
in time.

> 
> We are often get requests to edit documents external to our primary domain, 
> but which I mean documents that are not wiki or part of ubuntu-docs. For 
> example, the Synaptic Manual. There are a number of problems with this:
> 1. Moving out to do external docs detracts from our focus and therefore 
> diminishes productivity in ubuntu-doc. Naturally, we cannot stop people doing 
> external docs and don't want to stop them. We also want to help on other 
> things and do ubuntu-docs. We want to do everything :-)
> 
> 2. Where is the repos? It is time consuming to determine where the repository 
> for a given document is. Is there a snapshot in some server within the ubuntu 
> community, or must we go all the way upstream to get a copy against which we 
> can patch. Getting and installing sources from the software repository just 
> consumes disk space.
> 
> I wonder how we can manage this. Perhaps we can have a list of where to get 
> certain docs and grow that over time. A single place to find this info would 
> be a blessing. Do you want to discuss this problem?
> 

+ 1 on point 1.

+1+1 on point 2. I don't know how authoritive we will be on this topic 
without maybe discussing the issue (and what to do) with someone like 
jdub or mdz.

> 
> Sometimes we will have documents that are not strictly in the ubuntu docteam 
> project list. For example, I am writing a document on how to install kde for 
> ubuntu (kubuntu). It is an article type document. In the future it may become 
> part of a greater document by for now it is aimed at sufficing a simple need 
> to know how. So it can be called a HOWTO. Where would we put such documents 
> in the repos. Take into consideration your thoughts on the above repos 
> problems and vote here if you want to discuss your ideas.
> 

+1 the earlier we get docs into the repos (even if they are one page 
howtos), then the earlier the will start getting worked on, reviewed, 
evolved etc etc

> 
> Each of these topics will be spawned into sperate threads so that we can:
> a. focus on those thread in which we are interested.
> b. make it easier to follow and respond on topics.
> 
Excellent Ideas Sean!

Cheers
trickie(Nick Loeve)