Hiring Edubuntu Staff
ace at suares.an
Fri Jul 24 14:50:31 BST 2009
alan c wrote:
> It sounds as if there is a huge imbalance of expectations,
> particularly by the users, and I guess that most if not all users of
> edubuntu regard themselves more as 'consumers' of Edubuntu rather than
> users who want to be more involved with development.
I disagree on both counts.
It's not the users fault at all.
Even when you are stepping over the threshold to really help out, you
have to really shoulder you way in.
Efforts are now on the way to ease the difficulties for casual
contributors. I hope those will be successful
> Maybe Education is not like other areas using IT with server-client
> functions. I wonder if the IT skills and motivations of edubuntu users
> and edubuntu users admin are such that they are less likely to be
> attracted to app development etc than IT users and admin in other
An interesting thought. Your key 'mistake' is that you talk about app
development. No user wants to be in app development. Otherwise they
wouldn't be users.
Users want to be heard. That means that if they say 'this and this
doesn't work' they want to have it fixed someday soon. But without users
the devs wouldn't know half of the things they need fixed.
In lack of things being fixed, the users want to at least know that they
are being heard. So in reply to a bug report, at least something
should happen, like a status change, some acknowledgment. Users that
send bugs into space where nothing is heard of ever again, will stop
Then there's a lot of users, confident that things are getting fixed or
at least are getting heard, want to contribute with ideas, feature
requests and such. The mailing list can function as a catcher of those
ideas, as long as the response to some idea or feature request not is
negator; i.e. 'it can't be done', 'we would need to rewrite X for that'
New ideas and feature requests should be discussed on its own merits,
until a very clear request or idea comes out, snipped from all its false
assumptions of 'what one needs' and also integrated with ideas that
other people come up with. Only THEN should developers react with their
developer hat on.
When developers then finally discuss the technical possibilities of the
idea, and dismiss some ideas with 'yeah, if we had a quantum computer'
and accept others as 'could be done', then there ideally would be some
milestone as to when to implement.
But if there are not enough developers, then I say let the devs pick
Last but not least, it should be easy for users to share experiences;
please don't think that 'learn XML' will be a good answer to anyone who
wants to update the handbook. (Sbalneav is working on getting the
handbook into a wiki so that problem will at least be lightened).
Users should easily share their experience; whether it be stories or
whether it be documentation. Their documentation should be vetted. By
the devs. And preferably cleaned up by a user that does nothing else
then correct grammar English and speling.
The user contributed documentation should be vetted. By the devs. So the
user can feel sure that it's really good documentation. That he or she
didn't forget a sudo here or there. That it is perfect, technically. So
the devs need to vet on technicalities, and please not on 'ace, you're
doing it wrong. NO ONE will use redir and a proxy to browse the
internet! Our methods are lots better. They have A and B and C. Why
would you want to document such inferior technical solution?"
User should feel *protected* by the devs, so they know if they would do
something stupid (mess up the docs, wrong tech info, expose private info
in ip addresses and such), they know that will be corrected. They also
should know that ANY documentation is worthwhile even if it is
technically inferior according to the devs. The structure of the
documentation may put some solutions more prominently then others but it
should be all there, and encouraged.
Hope You Read This Twice.
> My best wishes to the developers and users.
More information about the edubuntu-users