Hiring Edubuntu Staff

[alan c]

Ace Suares wrote:
> 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

Thanks for such an interesting reply, and its clarity.
As an outsider who cares, it is not immediately obvious how things
will move forward in a beneficial way. It seems that more developers
are unlikely unless newcomers are attracted, and frustrated users may
not seem attractive......

The wiki format handbook sounds a very good move. More power to
Sbalneav's elbow!

> Users that
> send bugs into space where nothing is heard of ever again, will stop
> filing bugs.

I agree. The several bug entries (in ubuntu) that I have filed, at
least got responses. Not ones I always wanted, but I did feel a part
of it all.  Maybe feedback to users is the key area for action, even
though resource might not be available currently? This resource might
not require a high level of 'developer' skill, but an ongoing
systematic energy with easy close communication with the few developers.

What action has been taken to try to get more developers? Is there a
way of calling for volunteers?
-- 
alan cocks
Ubuntu user