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 _______________________________________________ design-team mailing list design-team@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/design-team
