<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Tuesday 30 June 2009 03:40:31 Rodney Dawes wrote: > On Mon, 2009-06-29 at 15:51 +0200, Kenneth Wimer wrote: > > Well, that is not strictly true. We did have a discussion or two about > > it in the past but nothing concrete came out of it. > > Right. Let's change that then. Congratulations. You are now a > co-maintainer of the spec. What I meant by my statement though, > was that nobody has enough free time, willingness, or cares enough > to take on the task by themselves. Right, I've followed this list closely and think I know exactly what you mean :) > > I would love to help if you'll take me ;) It seems to me that the > > first thing needed is a more formal request process. It gets quite > > hard following a discussion about an icon in an app on a desktop you > > don't use - and nobody can be expected to install, use, understand and > > like everything. > > Yes. Which is why we need more discussion from both sides. GNOME > developers demanding icons go in the spec, and no input from KDE or XFCE > developers isn't very helpful either. And I think your work in both KDE > and the Ubuntu artwork community could help with that as well, by > stirring up a few people into discussing the requests. > > > In addition, much of these requests get lost/forgotten after a first > > decision has been made: collating the information and storing it for > > the future would be better. At least I know it would help me :p > > Another reason to suggest using Launchpad Bugs to track their status. > It provides meaningful status field information, priority, and threaded > comments via the web and e-mail. It provides a nice place where only > the relevant pieces can be viewed, unlike the current mailing list, > which can get easily bogged down by unrelated threads, leaving the > icon naming mails somewhere way down in the folder making them harder > to find and track. Launchpad would be fine by me. As someone who had to learn launchpad coming from bugzilla it is quite a bit different but the differences, in this case, are exactly what we need. If there is another solution which offers the same flexibility and amount of information we should look into it but bugzilla does not seem to be the right tool for really getting this problem solved. > > Anyway, I'll help, if you'd like. > > I would very much appreciate your help. Welcome aboard. :) > > The first thing we need to do is decide on a method of tracking icon > requests and dealing with discussions on them. Which is what this > thread was for, until it became yet another flamewar about the spec. > I vote for using Launchpad Bugs for this, for the several reasons I've > already stated a couple times now. I'm not going to force people to use > it if the general consensus is not to, though, which is why we have this > thread, so that people can present alternate or better solutions. Using > LP Bugs wouldn't be a permanent solution, but simply something to use > which will more than suffice, until we can get a more specific solution > designed, implemented, and deployed. > > What do you think new co-maintainer? Sounds good to me. Personally, I need to wrap my head around exactly which features/information we need and try to better define the processes both short and long term. -- Ken</body></html>