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

List:       kde-usability
Subject:    Re: KDE Quality Team implementation
From:       Tom Chance <tomchance () gmx ! net>
Date:       2004-01-03 21:00:00
Message-ID: 200401032100.00502.tomchance () gmx ! net
[Download RAW message or body]

On Saturday 03 January 2004 20:46, Carlos Leonhard Woelz wrote:
> > Would it not be worthwhile involving those who won't go on to get
> > involved in CVS accounts, submitting patches, etc? I mentioned this
> > scheme to my girlfriend, an avid KDE user, and she got quite excited
> > about the opportunity to work on KDE without ever needing to get into the
> > development side of things.
>
> That is exactly what I want!

My apologies. From your other post I got the feeling that you wanted all 
Quality Team participants to get involved with CVS etc.


> The idea is to design the Quality Teams in a way people like your
> girlfriend are interested to work.  I don't want to say to people what
> people are going to do. But as they grow inside the project, they will
> integrate more with the normal environment, as the docs/i18n teams do, they
> will get bugzilla accounts if they do not want to mess with cvs, they can
> write docs and articles, and talk to users. It is their choice.

That sounds great :)


> But we could separate the tasks that need "deep" involvement and the ones
> that don't in two guides, for the two audiences. The big advantage is that
> you would not scare people away if it is too complicated. But the problem
> is: some things _are_ complicated. So we still need the guide for the
> complicated ones, maybe a step by step guide.

I think we ought to be careful about setting up a false dichotomy here; 
differences between people will be more fine, more of a spectrum. Your idea 
of presenting the simple "sales pitch" information alongside the full guides 
to all of the different tasks would work well, since everyone could read and 
understand the sales pitch documents, and then pick those tasks that they 
like and understand.

> There is nothing wrong with the pilot. If you think starting with a pilot
> is better, and we can include at least three smaller apps, or two apps if
> they are bigger, or Konqueror alone (just kidding, messing with Konqueror
> in the pilot is to ask for trouble) ;-) And the advantage would be more
> communication inside the group, since we would be talking about the same
> apps. Yes, that's a good idea. hmmmmmmm OK I support the pilot. We include
> kde print and ark, so Kurt and Henrique will be happy ;)

I'd suggest either kdeprint or ark and an "interesting" application like 
Kopete or a game, just to attract more people, but if enough people can be 
found for those two that sounds fine :)


> The proposal does allow people with less technical skills and less
> willingness to hear about development discussions. The mailing list should
> be the place to discuss things, send contributions and expect feedback.

I'm still uncomfortable about putting people on devel mailing lists. Then 
again, I don't know what the traffic is like, and I have no empirical 
evidence to base my discomfort on, so I'll leave it at saying that I think a 
list with 10+ emails a day that aren't relevant to the quality team will put 
people off. But then I'm looking at it more from the point of view of the 
benefits to the participants than the benefits to KDE, so as a KDE venture 
maybe you should take KDE's concerns more seriously than mine :)


> The website will be an eternal work in progress, and the intention is to
> have a wiki version of the key points (the guides) so it is easy to
> contribute.

That sounds like a very good idea. It would be interesting to see Quality 
Teams working with or contributing to the usability/accessibility groups 
through this, as I'm sure Quality Teams will begin to develop documents on 
working around UI design and such issues.

Tom
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]