[Design-team] The Theme

Martin Sourada martin.sourada at gmail.com
Thu Jun 18 22:31:13 UTC 2009


On Thu, 2009-06-18 at 17:28 -0400, Máirín Duffy wrote:
> On Thu, 2009-06-18 at 22:56 +0200, Martin Sourada wrote:
> > On Thu, 2009-06-18 at 09:55 -0400, Máirín Duffy wrote:
> > > We still need a default. We could pick one of the ones we select to be
> > > the default one, but have others along the same theme available as
> > > options. Adding another dialog I think isn't a good idea.
> > Think of Live CDs. We don't have the space to ship more wallpapers in
> > our default install...
> 
> Don't we ship a small selection GNOME-provided wallpapers in the LiveCD
> as well? Couldn't we swap those out?
That's a question rather for the Desktop team... Also we should think
about KDE as well. I recall they usually have even more space problems
than the Desktop spin... Not sure about the other spins.

> > 
> > > > Honestly, I am not a big fan of this approach, is like us dropping the 
> > > > ball and acknowledging we are not able to create ourselves something 
> > > > good enough.
> > > 
> > Me neither.
> 
> Why do we have to create the wallpaper ourselves?
Why should we take the wallpaper from outside? I think that since we
took over from Diana the release artwork job, we've built quite a good
reputation of always coming up with awesome original works. I am not
necessarily against using works of people outside the team, but I feel
it would be like admitting we aren't able to create it ourselves. I
still believe that not to be the case. 

> I *am* that desperate. The past 3 releases have been miserable for me
> personally, and I did literally have to drop everything going on in my
> life and spend late nights on the wallpaper.
> 
Yeah, I know... It's been really hard for you and I am most grateful
that you did what we failed to do. But we should rather think why. In F9
it was because we tried to do two things at once (the Round based
approach and later tried to mingle it with release name) and failed in
that - and had to do the things anew late in the process. In F10 we
failed because Samuele didn't correctly understood how to properly reuse
works of others and we again had to replace most of the artwork at last
minute :-/ In F11 we tried a new concept and again tried to do too much
things at once. Plus, Samuele came up with new idea 5 minutes past
twelve. We *really* need to avoid that.

My point is -- learn from the mistakes of past and but be also aware in
what we were good at. In all cases where we failed, we failed because we
had to redo the artwork anew late at the process. We should really avoid
this.

> Fedora 9 was the worst. With Samuele's help in F10 and F11 it's been a
> bit easier but not much. If there is someone passionate and motivated
> enough to take the responsibility for the theme from me and push for
> original created work then please do - I do not want to do it!
> 
Yeah, we totally need people to actually do more than just submit
ideas...

> We had *one plan* we followed for *several releases*. There were
> problems with it so we tried something new: We can't discover the right
> approach if we don't try different ones, but it has not been a different
> approach every single release. It was the same approach every release,
> and a different one for F11. 
> 
I think that plan worked pretty good until we tried to mingle it
together with release name (in F9)... In F10 we reverted back to it, but
failed, I wonder what exactly went wrong...

> How could the F11 process have been clearer? It was documented on the
> wiki: http://fedoraproject.org/wiki/Artwork/F11   What are the problems
> with this? How can we do better next time? I do not think having two
> processes is going to simplify at all, so I am not sure how well that
> proposal will help.
> 
The problem was that it was completely different and people weren't
fully prepared for that. Also the communication within the team seemed
to be a little bit off (or maybe it was just me not reading the mails
properly?). I'm not sure. Confusion sure comes to mind, but I fail to
pinpoint the exact reason for that :/ If I recall correctly I frequently
didn't know how far we are -- i.e. what is already created and what
still isn't, which artwork is supposed to be official and which
isn't... 

Perhaps we could use a simple bug track to track our tasks? Or would it
be an overkill? I can see the advantages of people being able to more
closely follow the process and also people claiming tasks knowing that
others didn't claiming those yet. Plus people would have better idea of
how far we are. But it would pose additional work on us...

As for having two processes -- yeah, it's probably a bad idea, what I
had in mind something like having some kind of fallback if the process
itself fails... Well, if don't base our artwork on release name, we
could keep it for more than one release, if necessary. But it would feel
awkward if it would be based on the release name... Or perhaps have a
completely new artwork with every odd release and have an
improved/slightly changed version of the previous one with every even
release? Are we really have problems with time, or is it just because we
tend to do the things last minute? Or is it lack of people?

> It seems there are complaints about the process, then complaints about
> changing the process in trying to improve it. How can we improve the
> process that people complain about so much if we can't change it?
> 
I think, we often have problems when we change the process completely.
It seems to take some time for people to adjust... Perhaps analyzing
what parts of the current process are worst and how to improve them
would be a better approach than trying a completely new process again?

> Does anyone want to take up the task of writing and maintaining the
> theme process documentation, and making sure it is well-publicized?
> 
We need to decide on the process first, than documenting it... I can put
together a draft of what outlined before tomorrow if people think about
it as a good idea. We can even put different drafts together (although
it seems I and Nicu are not fans of your idea, it does not mean it might
not turn up to be the best after all) and then discuss what might be
best. FUDCon is next week and the release name will be supposedly
reported there, so we still have some time to decide on the process for
F12.

> > > The main problem for me is that every time the topic of release art
> > > comes up, I don't think 'fun' and 'cool', I think 'pain' and get a
> > > feeling of dread and despair :( And that's not cool. And after going
> > > through all that hard work and time, still we get negative comments (and
> > > I understand we can't satisfy everyone, but that on top of having to
> > > work so hard and not have much fun, makes it even less enjoyable.) I
> > > feel that this problem should be addressed so we can make theming fun
> > > again, but I'm not sure how. This was the idea I came up with but I'm
> > > very open to other proposed solutions.
> > > 
> > > Is this fair or am I being overly dramatic?
> > What I feel when I think about fedora themes is high entry level and
> > confusion about the process.
> 
> Do you have a better idea? Can you commit to helping make it better?
See above. But to summarize and perhaps add something more: 
      * try to change the process slowly rather than radically, based on
        experience from previous release(s)
      * after each release is done, hold a session (on irc with summary
        posted on the list and wiki, or on the list only?) to discuss
        what went right and what went wrong and what can we do about it
      * better track what needs to be done and who's working on what
      * create rather abstract themes than photo manip.
      * have a direct link to the current release artwork process from
        our front page
      * be stricter about deadlines
      * don't expect Mo will do the dirty work. Our artwork must be a
        community effort, not our leader's all nighters (yeah, I am also
        to blame here, but at least I've tried to help with the
        wallpapers a little)

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/design-team/attachments/20090619/0dc9140a/attachment-0001.bin 


More information about the design-team mailing list