Logo lessons
To reiterate: the logo is done. I know that everyone would like "just a
little more time," but a little more time will satisfy no one, because "a
little more time" will not result in substantial changes. It's time to
put this episode behind us, and figure out what we've learned.
As the new logo continues to make its way through the world, the opinions
will vary widely. As always, the people who hate the new logo will be the
ones who voice their opinions the loudest. Get ready to hear that the
logo is a horrorshow, because you'll hear it a lot -- for about a week.
Again: the community will not rally round the flag, or refuse to rally
round the flag, because this logo is or isn't perfect.
They will, however, judge us on how we chose to come up with this logo.
If we made some mistakes, and I believe we did, then we should acknowledge
them. I think that Jef is correct in his analysis. In hindsight, we
should have:
a. Had more than one concept for the community to examine;
b. Advertised more widely that we were working on the logo -- and
also, advertising that the place for those logo discussions
was this mailing list.
So we'll learn those lessons and we'll move forward.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
On Wed, 9 Nov 2005, Jeff Spaleta wrote:
On 11/9/05, Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
> * Should we have gone through more iterations, or would more iterations
> have dragged things out even longer?
Strictly speaking I think neither. I think the missing element isn't
iterations or time per iteration.. but an aspect of choice, limited
choice.
Whether it be a discussion of default background, or codename, or
logo. I'd like to see 2 or 3 reasonable choices presented for feedback
before the final decision.
To me most discussion should run sort of like this:
1) very free-form brain-storming discussion with lots of crazy crap
from this debate comes a sense of bounds as to constraints on the
solution space.
The more variety of out of bounds ideas you can generate the
better you understand
the boundary of the problem. And you hope to get a sense of
important themes that a
solution should try to incorporate.This is the discussion that
puts the item on the map
as an action item. No-one should expect a solution to come fully
formed from
this discussion.
2) applying the constraints, task a team or individual to spin up 2
or 3 solutions which
individually meet the constraints but provide different
interpretations as to mix of
important themes. Make sure its clear how the final decision is
going to be made at this
point.
3) focused feedback discussion on those specific 2 or 3 choices.
This allows for some ability to compare and contrast between the
presented choices,
instead of degrading into a simple "this sucks." Most likely, all
choices will be equally
recieved across the spectrum of interested people.. publicly
validating the fact that any
of the set of choices will serve equally well/poorly.
4) final decision is made however was decided in step 2.
If we fell down in this discussion, its in the fact that we only had
one draft for consideration which met the constraints at step 2.
-jef
--
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list