[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    wishlist bugs and community management
From:       Lydia Pintscher <lydia () kde ! org>
Date:       2010-03-27 14:36:28
Message-ID: 938b46781003270736s4348b5aco158f2e919b3d1c2a () mail ! gmail ! com
[Download RAW message or body]

Heya folks,

sorry for starting a new thread but I'm not subscribed so please CC me.

This is a bit of a tricky topic as you can tell from the rather long
discussion you already had. But let me give you a bit of advice. I
hope it helps.
So there are different things mixed into all of this - among them
barrier of entry, quality of wishes, perceived power of the core team,
spreading the community out too much and keeping it too close
together.

Barrier of entry: With every hurdle you add, no matter how small and
what kind of a hurdle it is (people, processes, ...), the number of
people who will do something for you will drop dramatically. In your
case this would be getting rights to edit bugs in bugzilla or getting
another account on service X. There is two sides to this: In bugzialla
"normal" contributors shouldn't need rights that they can't get
without someone's approval but they might not be aware of that and
editing a bugzilla entry is scary anyway for newbies. Getting an
account in service X is also a barrier that some will not be willing
to take.

Quality of wishes: However you also need to consider the quality of
entries you get. With an ultra low barrier of entry you will also get
a lot of low quality contributions that might not be worthwhile to you
and even cost more of your time than it is worth.

Perceived power of the core team: Definitely a problem for some people
but that's something you have to live with I think and do as best as
you can.

Spreading the community out too much vs keeping it too close together:
Spreading the community out too much can hurt it really badly -
especially a small community. It looses the feeling of being part of a
team. The shared place is too big to really stick together. And worst
of all information gets spread out so much worst case that no-one has
the time to keep up with it all. Spreading it out otoh has the big
benefit of allowing people to get used to working with you while not
having to commit fully to a bunch of possibly very scary hackers. (Yes
I know you're all sweethearts but $newbie doesn't know that ;-)) It's
easier to get into the cold water step by step instead of jumping
right in and getting a heart attack so to say.
The other thing you have to keep in mind is: Where do all of you have
accounts? And do you check them regularly? I doubt this for launchpad
for all of you tbh for example. There is no use in such a system if
not a considerable number of people from the core team are actually
looking at this and interacting with the people filing wishes there.
Nothing is worse than having a place where wishlist items rot to
pieces. Nothing says "We don't care" more than that ;-)

Then there is of course also the question if bugzilla is the right
tool for wishes anyway. Imho it is not necessarily. Starting with the
fact that you can't actually downvote an idea and the fact that it is
a pretty hardcore tool that is too much for the people you might want
wishes from.


Taking all the above into account I would recommend going with
brainstorm on the KDE forums. The reasons:
Some of you have accounts already and use them.
It is a dedicated solution to actually handle wishes.
It has a team that actually takes care of giving feedback in case you
can't keep up with it as well as you would like.
It is close to KDE as opposed to launchpad for example.
The barrier to entry is relatively low but entries are pre-screened by
the forum team to shield you from the worst.
There is actually a community voting on wishes that is not the typical
hardcore crowd you get on bugzilla.
The tool itself is a lot more friendly to non-hackers.

This is of course just a recommendation. Let me know if you have questions.


Cheers
Lydia

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]