[Design-team] The Theme

[Paul W. Frields]

On Thu, Jun 18, 2009 at 10:12:24PM -0400, Máirín Duffy wrote:
> On Fri, 2009-06-19 at 00:31 +0200, Martin Sourada wrote:
> > 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.
> 
> This is a good point. Although I wonder how much you can really control
> a creative process. I think the thing that scared me the most about the
> late nights - I could spend hours and hours and hours and have to throw
> it away. There wasn't any guarantee after x hours there would even be
> anything usable.
> 
> > Yeah, we totally need people to actually do more than just submit
> > ideas...
> 
> How do we encourage the follow through we need? :-/

There is a release schedule that we've tried to use previously as a
way of making sure everyone knows what tasks are at hand, and when
they reasonably need to be done so no one has to pull all-nighters or
get stressed about our design components.  What if we had a Design
Team meeting with John Poelstra to set up these dates, and then give
him permission to remind the team of upcoming dates?

Alternatively, or in addition, we could set tickets in the Design
Team's Trac instance that would help the team look at an easy
dashboard for what remains to be done for F12 design.  I'm of two
minds about the Trac instance, because I don't want the team to feel
forced to use it, because it's Yet Another Tool (possibly).  At the
same time, it's a *very useful* tool that many other groups are using
for tracking their work queues.

And hey, on a positive note, let's keep in mind that a couple things
did go very well in F11's cycle -- for instance, as we wanted, there
was a desktop background ready for the Beta.  That was an improvement
over previous releases and you guys should take some credit for it.

> > 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...
> 
> I think this is a good idea. Maybe for each piece of artwork that we
> need, that's in the schedule with a deadline, we open a trac bug in our
> new trac instance Paul had set up for us? That might work well.

What if there was a dedicated Design Team meeting once every week or
two to check status against the artwork schedule?  The Trac instance
gets more useful if the team agrees to review the queue on a regular
basis to see that things are moving forward.  I know it seems like
less fun than the creative process, but I'm really keen on making sure
that we don't avalanche toward the end of the cycle with all the
snowballs falling on one or two people.  Would the team be willing to
do this?

[...snip...]
> > 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)
> 
> Is the above proposal slow enough? We're keeping the
> inspired-by-the-release-name theme, but clamping it down a bit more by
> requiring vector artwork and abstractness.
> 
> We could handle the 4 broader-community readymades as a separate
> project.

Does this mean that there would be a fallback to some default theme or
background if we miss the particular deadlines?  In other words, is
the plan to build a safety net that is something other than the
dreaded all-nighter(s)?

[...snip...]
> >       * better track what needs to be done and who's working on what
> 
> I think maybe the trac ticketing system can be a big help here.

I would hope so too -- if the things that are filed there are brought
back up on a regular basis, so that it's not just adding the work of
filing tickets without any other benefit.  That's probably the basis
for my mixed feelings about Trac -- I was hoping it would help the
team for everyone to agree that both filing tickets, and reviewing the
queue regularly, were worth doing.

[...snip...]
> >       * be stricter about deadlines
> 
> +1

I think this ticket review process would really help -- there are no
surprises for anyone.  And if something falls on the floor for lack of
attention, then it's fair to simply let it do so.  And having a
fallback means that there's no catastrophe, and no one's held hostage
to unreasonable expectations.

> >       * 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)
> 
> Yes please :) :) :)
> 
> And thank you for your patience with me :)

It's good that the team is having this conversation.  If everyone can
agree on a set of solutions, I know there are people around to help
empower the team to put them to work, including John and me.  We want
you guys to have the tools you need to succeed, and you guys provide
the creativity.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug