Proposal: Create product for each derivative's documentation

Cody A.W. Somerville cody-somerville at ubuntu.com
Wed Apr 8 13:16:18 UTC 2009


On Wed, Apr 8, 2009 at 5:49 AM, Matthew East <mdke at ubuntu.com> wrote:

> On Wed, Apr 1, 2009 at 4:18 PM, Matthew East <mdke at ubuntu.com> wrote:
> > On Tue, Mar 31, 2009 at 3:03 PM, Cody A.W. Somerville
> > <cody-somerville at ubuntu.com> wrote:
> >> This will continue to occur using a project group.
> >
> > I have two problems with using a project group for the ubuntu-doc
> project.
>
> {snipped}
>
> I'm raising this issue again because I don't think it is a good thing
> that different parts of our project are using a separate project
> (xubuntu-docs) and different parts are using a single project
> (ubuntu-docs, kubuntu-docs, edubuntu-docs). I've already seen some
> confusion start to grow with translation teams about where to find our
> branches and translations as a result of this change, and I think we
> need to plump for one way or the other.


Could you show me where I can see evidence of this confusion? Where
translations occur has not changed.


>
>
> As I've said in the past, I don't think the project group is the right
> way to go, and I won't repeat myself about my reasons for that, but we
> need to settle on a way of doing this that is consistent.


I think we need to be consistent and use launchpad as it is intended to be
used and how it is used by the greater Ubuntu and launchpad community. There
are clear benefits to the Xubuntu documentation team to have its own
launchpad product whereas there is loosely held together dogma supporting
the current abomination which although has commendable intentions has proved
to be of little benefit.

Frankly, I'm beginning to wonder if you just want it your way for the sake
of having it your way; that the imaginary idea of having all the branches in
a single launchpad product provides you with some comfort that it *might*
make people more willing to collaborate. Clearly this ideal is a fallacy and
I wonder if even the reverse might be true. If I were someone interested in
contributing to Xubuntu documentation, I might go look for the Xubuntu
documentation product which with your way of doing things I would not find
nor be directed to the Ubuntu doc project. Even if I did find the ubuntu-doc
project, it hardly mentions Xubuntu and the actual branch in the UI is a
single narrow row in a table. I think that with having the Xubuntu
documentation product, it'll be clearly easier for new folks to find what
they're looking for. Having those new contributors contribute to the greater
Ubuntu documentation project is a community process and not something that
can just be made to happen by the way we suboptimally configure a launchpad
project.

There is no slippery slope here. Following the appropriate launchpad idoms
will not result in further fragmentation of the documentation team but
instead improve the workflow for contributors and actually be natural for
folks coming in from outside the doc team. Infact, I think it is the Ubuntu
Doc Team's blatant refusal to actually consider new procesesses and new
toolchains, let alone implement, that has resulted in such poor returns from
our iniativies to recruite new contributors. Doing things differently and
awkwardly with our setup on launchpad only heightens the already too high
hurdle for new contributors.


>
> Can others in the team express an opinion on this issue?
>

> --
> Matthew East
> http://www.mdke.org
> gnupg pub 1024D/0E6B06FF
>

Cheers,

-- 
Cody A.W. Somerville
Software Systems Release Engineer
Foundations Team
Custom Engineering Solutions Group
Canonical OEM Services
Phone: +1-781-850-2087
Cell: +1-506-471-8402
Email: cody.somerville at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20090408/f99f72c1/attachment.html>


More information about the ubuntu-doc mailing list