Hiring Edubuntu Staff

Ace Suares ace at suares.an
Fri Jul 24 14:50:31 BST 2009


alan c wrote:
{snip}

> 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
> industries.

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 
filing bugs.

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' 
etc etc.

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 
their priorities.

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.

Ace
















> 
> My best wishes to the developers and users.




More information about the edubuntu-users mailing list