[ubuntu-art] Kyūdō: Working on the Foundation

[Mikkel Kamstrup Erlandsen]

2008/10/5 Thorsten Wilms <t_w_ at freenet.de>:
> On Sun, 2008-10-05 at 10:50 +0200, Mikkel Kamstrup Erlandsen wrote:
>
>> I am a bit unclear about the scope of Kyudo. When you talk about
>> "themes" I get the idea that it is only about the desktop theme
>> (traditional gtk+metacity+icons+gdm (+bootsplash etc)) is that right?
>
> Yes.
>
>> Because my idea of a "whole unified presentation" also involves themes
>> for the relevant web sites out there, as well as providing web buttons
>> and flags people can use in their blogs and probably other things I
>> haven't thought of.
>
> Yes. Defined as "presentation" within Kyūdō. The long term goal is to
> achieve an optimal presentation. But currently it's all about the theme.
>
> Because one can't tackle everything at once. The theme defines what
> people look at for the longest duration. You can create and offer a
> theme without special permissions. So to have a chance to at least
> influence say, the main website design, the idea is to first prove
> ourselves with a theme. Finally, I assume that one will find the most
> tight requirements for the theme, making it easier to adjust other parts
> of the artwork, where you will find more freedom.

Ok, good. This was in fact what I was hoping to hear :-)

>> Would something like:
>> http://fedoraproject.org/wiki/Artwork/DesignService make sense for the
>> art/kyudo team?
>
> Perhaps. You could argue that requests to the mailing list are the way
> to go, but maybe this possibility isn't obvious/clear enough.

Ok. No need to consider for now; as you said yourself the theme is the
first area of focus.

>> Another thing I can not fully figure out, more related to the /Process
>> document... Roadmapping; it is not expressed that stuff should be
>> roadmapped (with dates/deadlines!) - it not only helps you (and more
>> importantly: others) in accessing whether you will be ready on time,
>> but in my usual work flow this is also a key element in evaluation
>> part of the work.
>>
>> Historically we have tried a bit of half-hearted road mapping, but it
>> has always just ended up outdated and misleading, so that is a good
>> reason to avoid it otoh. If one does not stick to the roadmap and
>> update it frequently it is actually better not to have (a public) one.
>
> The next release plan will set important dates for everyone who wants to
> work on themes for Jaunty Jackalope. Apart from that, currently, I could
> only make a plan for myself. But things have to happen as I get around
> to them.
>
>
>> Last clarification: Leadership. What will the structure of the
>> organization be? The current complete non-organization of the artwork
>> team is a disaster nothing less, that is my humble opinion at least.
>> Things such as a clear decision making process and responsibility
>> assignment are paramount if Kyudo is meant to have a professional
>> workflow and be more inviting to cooperations such as Canonical.
>
> Said disaster was part of the motivation. We are all volunteers here,
> you can't push people around, as much as I would like to ;)
> My allies and I want meritocracy. Leadership by example, skill and
> effort. At some point, official roles might be introduced.

One does not need to push people about to be a leader. A better way to
phrase it might be "responsible person" or even just "contact person".
This is very handy when trying to stick to a roadmap. Also when people
go absent: When (not "if", but "when") the Roadmap Responsible takes a
long vacation anyone should be able to step in as replacement because
it is really just about collecting the various contacts of the sub
projects and get status reports from those and update the roadmap
accordingly.

I am more or less the "contact person" on the Xesam project for
instance. I don't have the rights to pull decisions, but I am
responsible for them being made and recorded in the right places. Also
I am mostly the one people go to when they inquire about Xesam stuff.
I believe most people are very happy with this arrangement, I have
received several nice words about this model.

Breaking the tasks into smaller well defined components should also
make it less daunting to accept the responsibility of one of them. A
"Roadmap Contact" might have the job description: "Make sure the
Roadmap wiki page is up to date and maintain the list of contacts for
the sub projects", that is easy an simple to live up to and should
take too much time. Maybe this could even be managed inside
launchpad...

> I would be glad to share the responsibility for parts of Kyūdō, but will
> likely always see the big picture as my job.
>
>
>> Anyways these are just my opinions and you should of course take Kyudo
>> in the direction that makes sense to you. And thanks for the excellent
>> documents, I read them with delight :-)
>
> Glad to hear that, but really, you should get involved. Make Kyūdō
> broader and more solid, save us from the blind spots of a single person!

I can not get involved more than a bit of commenting and review
although I would like to. I simply don't have the time as I am running
a few too many other FOSS projects on the side already :-)

However feel free to use me as a "technical consultant". As I am no
stranger to Gnome development I might be able to service a few
requests regarding "can you create a patch to Murrine that does
<foo>?". I have done that in the past at least. In case we go serious
about one of the patches I can also work with upstream on the
integration.

Please ping me directly in these cases as I don't read ubuntu-art that close...

-- 
Cheers,
Mikkel