On Fri, Aug 5, 2011 at 12:59, Allan Day <allanp...@gmail.com> wrote: > Luc Pionchon <pionchon....@gmail.com> wrote: >> What about? >> - be open >> - listen to the feedback, >> - don't give canned answers >> - engage in constructive discussion, >> - avoid derision >> - show interest in feedback >> - get to the facts; >> - go to the source, tackle rumors; what is it founded on? >> - if needed, go through a few levels of "why" to reach the point >> - use numbers >> - avoid vague quantities "so many", "a lot", "several", etc. >> - encourage people to report more formal feedback (mailing list, buzilla, >> wiki) >> - really, listen to the feedback > > That's a really good list! (It would be awesome if you or anybody else > wanted to do a wiki page on dealing with feedback... ;) )
This is easy to do. Where would you put it? > One thing I would say though - some of those things (constructive > discussion, get to the facts, go to the source) don't work so well on > public discussions in my experience. They're great things to do, but > they only tend to work when you're have a discussion with a small > group or even on a one to one basis. I don't quite get it (sorry). Do you mean that discussion between many passionate partisans tend to be messy? What I mean is that, if you enter the discussion, do it in a constructive way. It's about tackling empty, fallacious, or too vague statements ; and get to the point. It's about pro-actively extracting valuable feedback. Unhappy users clearly have something to say. But they do not have to wear white gloves and serve it to you on a plate. It is their freedom to just vomit it. On the other hand the authors of a project should be open to feedback, it's then up to them to go and extract the feedback. -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list