Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 17459 ideas, 107690 comments, 2263278 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas
Idea #13674: Keeping our existing Ubuntu developers.

Written by Hobbsee the 25 Sep 08 at 03:18. Category: Others. Related project: Nothing/Others. Status: New
Rationale
Currently, we're attracting lots of new developers. This is great,
but unless we keep our older developers, things like sponsorship,
and getting general advice about what people should do in
situations, becomes a problem. I think we need to look at why we're
losing people, and what we can do to slow this flow down.

Inevitably, we will lose some people, due to them focusing on other areas of life - but I think we're losing people at a faster rate than
that. This also has implications for Ubuntu QA.

Possible reasons for inactive developers:
* Developer gets involved in work / significant other / too busy
- Make sure that all important decisions get announced
somewhere, so people don't have to follow IRC to see them all.
This then allows more time for them to do uploads, and less
time spent reading irc logs.
- Wiki documentation!
* Developer gets bored
- How can we solve this boredom?
- Variety in work
- Give people different levels of privileges, as they show more
skill?
- Encourage people to get involved in release teams / archive /
whatever other things they're interested in, but don't perceive
that they're allowed to join.
- People in positions of leadership in MOTU need to actually lead
- Accountability? (both leaders and mere mortal MOTUs)
- REVU for intrepid, failure of REVU coordinator?
- Lack of mail about what actually needs to be done
- for new contributors, and seasoned contributors
- Time estimates for tasks?
* Developer gets disillusioned
- Decisions take too long to make
- People don't show up to meetings
- various other reasons
- People.ubuntu.com & Canonical/Community split.
- How do we solve this?
- Make sure decisions get made as quickly as is feasible
- Help people to care about MOTU - it's not just upload
rights - it's working in a fun team.
- Make sure the team is actually a fun place.
- People should be proud to be MOTU - why aren't they now?
- Issues of identity of MOTU, the team.
* Other burnout
- As above, focus on getting the important information from MOTU
out in a compact package, so people don't need to spend as much
time on ubuntu - before or after they're burnt out
- Decrease sponsorship times, for various teams
* Developer difficulty with launchpad
- Launchpad liaison should help with this.
- This should be addressed in another brainstorm idea.
- Ways of finding useful things developers can do, quickly?

Questions raised:
* How can we ensure that work on Ubuntu is fulfilling?
* How can we reduce the time commitment required to work on Ubuntu?
* How can we ensure that Ubuntu is a welcoming place to work on Linux?
* What sort of information would be most useful, in a digest version
of Ubuntu development?
* How do we alert people to new opportunities to help?
-Ubuntu-devel-announce list?
* Who is wanting to be involved in this effort to get things changed?
Will they see it through until it's finished?


Developer comments
Also replicated at http://hobbsee.com/tmp/brainstorm.txt and is likely to get updated there.

105
votes
up equal down
Solution #1: Auto-generated solution of idea #13674
Written by Hobbsee the 25 Sep 08 at 03:18.
Ubuntu Brainstorm was updated in January 2009. Since the idea #13674 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

Propose your solution

Attachments
No attachments.


Duplicates


Comments
cheesehead (Brainstorm moderator) wrote on the 25 Sep 08 at 18:10
Ooh! Personnel issues! Happy day! Familiar ground!

Personnel issues require a different technical skill set to solve than programming or packaging. Unless you reach out to community members who already know this turf, you'll work hard to imperfectly reinvent the wheel.

1) What is the magnitude of the problem?
What are the current and historical loss rates, and what is the goal?

2) What are the top problems (not the symptoms)?
Many of the proposed reasons -bored, disillusioned, burnout- are morale issues. Morale is a symptom, what are the problems feeding it? Leadership? Workflow? Training? Recognition? Politics? Have there been any useful surveys or other organizational-climate data?

3) Is the structure in place to implement a solution?
Identifying the problem won't help if the orgzanization's leadership structure can't -or won't- fix it. Does Ubuntu train it's volunteers to do their tasks the Ubuntu way?
Does Ubuntu train it's leaders -paid and volunteer- to...well, lead the Ubuntu way? Running meetings? Supervising work? Setting goals? Counseling and evaluating team members? Recruiting, training, and retaining team members?

Meryl wrote on the 26 Sep 08 at 00:07
Whilst I have no personal experience with the internal intricacies in Ubuntu / Canonical my comments here are purely from an outside perspective that I hope will bring more clarity.

* It takes a lot of guts and careful consideration to go out on a limb and post an idea like this... Hobbsee is to be commended and supported for this idea.

* The publication of an idea like this usually indicates the problem is fairly widespread and becoming endemic. Be mindful that personal responsibility, apologies and issue-resolving collaboration is more effective than blame-shifting, investigative task-forces and political rhetoric. This idea should prompt a call to action.

* Leadership, Politics, Recognition and Training are usually the primary causes of the problem. This is where extreme care needs to be taken; Ubuntu must guard against the current trend in the corporate world that seeks to oppress and exploit producers, developers and workers while the upper echelons get all the accolades yet do SFA. Do some people need to be reminded about Ubuntu philosophy and governance?

* Ubuntu developers are the jewels in the Ubuntu crown... where would we be without them? We have something very special here. Lets keep the community focus and always support one another. 'Humanity towards others': if a brother suffers, we all suffer.

Tree MendUs wrote on the 26 Sep 08 at 08:58
Hobbsee.
Great topic.
Expressions of empathy to all the Ubuntu (and upstream Debian) Developers.

I am not a developer, but would be interested in learning how to do packaging. But the way launchpad seems to work is not very efficient. Information seems to be in many places.

That's a view from the front end, but guessing about how the backend functions by how easy the front end is to use (for a range of functions), there might be some systemic advantages to improving the tools for the job.
ie "workflow" as identified by cheesehead (in 2), could be a problem - how can the tools help improve the workflow.

The following are suggestions for software tools. They may be present already, or not. There are a number of options for each type of package, so decisions can be made based on requirements of the developers.

I haven't used any "CRM" (customer relations management) or related packages (on servers), but a system that "tracks processes" would appear to be very useful for making smooth paths for information flow.

"Groupware" type server software might be useful for the communications, as it can allow a centralised mail/forum/chat/conference in the project - no need to go to another site, or use other programs. All the comms is within the project - so its easy to keep track of.
Recent news can naturally appear in a side column, or top bar.

"Project management", with gantt chart and calendar would help for planning and everybody knowing what the targets are.

"Surveys"/"Polls"/"Questionaires" to help get statistical information, and formatted comments for easy comparison.
So a statement like "I think we need to look at why we're
losing people, and what we can do to slow this flow down."
could be easily converted to ;
a) "Why are we loosing people - vote on these causes, and list others?"
b) "What we can do to slow this flow down?"

Easier ways to handle "bundles" of information. e.g. standard text for emails to standard questions, or better, just have standard links to the answers at wiki pages, even better have the information findable so people don't have to go doing long-handed emails.



Tree MendUs wrote on the 26 Sep 08 at 09:02
Hobbsee,

Would you be able to improve the layout of your idea?
(I know the text editor is not so great).

- a blank line before each new *... line
- maybe underline using ==== for the titles (takes a few "guess and re-edit"s)

e.g.

Possible reasons for inactive developers:

* Developer gets involved in work / significant other / too busy
===========================
- Make sure that all important decisions get announced
somewhere, so people don't have to follow IRC to see them all.
This then allows more time for them to do uploads, and less
time spent reading irc logs.
- Wiki documentation!

* Developer gets bored
==============
- How can we solve this boredom?
- Variety in work
- Give people different levels of privileges, as they show more
skill?
...

deadowl wrote on the 2 Oct 08 at 18:57
In my experience, developers don't get bored so much as they get exhausted. Development on Ubuntu requires a much greater degree of individual organization than I'm capable. That's what makes me "bored."

I want to have an IDE and install plugins for whatever languages I'm using with a debugging system (Python, C/C++, Java, PHP, etc), version control, package building, documentation, and bug-reporting system access. In addition to this, immediate access to feedback on such measures (I don't get your documentation) is also pretty essential.

Wiki documentation?
Yes, this is good, but the best thing to do would be to have the author of the code/app contribute documentation in a format that generates a wiki page. That author can then keep track of changes in the initial documentation and receive feedback when there's confusion/praise. In the case of confusion, the author could return to the wiki page and clarify himself more easily than probably anyone else could.

Variety in work?
Task management would be helpful here. It isn't so much about variety of work as it is about task duration vs. interest in task. Even if your interest is high, you can get burnt out from it and then return in a bingeful manner.

Give people different levels of privileges, as they show more skill?
Privileges should never be used in correlation with skill, but in the nature of the work that is being done by a person, and the level of trust that an oversight group believes can be had in that person.

People in positions of leadership in MOTU need to actually lead?
Don't know much about this, but it would seem a very difficult task with disorganized subordinates.

Lack of mail about what actually needs to be done?
A lot of people don't really follow what actually needs to be done unless they're highly committed to the success of the overall platform rather than staking their own interests in the platform. This isn't really correlated to time spent developing per se.

Time estimates for tasks?
Yea, the problem here is the learning curve of new developers. Not just in coding, but setting up their environment to their standard and understanding the code.

Decisions take too long to make?
Oh, this is a general problem of internet communications in decision making. Try promoting a more interpersonal setting when seeking to make decisions. Ex, VoIP conferencing as opposed to IRC.

People don't show up to meetings?
Another problem of using internet communications for this kind of thing. The root of the problem is that there's a serious lack of social investment in a chat room environment.

Developer difficulty with launchpad?
This is another one of those things that need to be streamlined.

My guess:

The biggest problem is overall development process organization. This will take quite a bit of time and developers to work on, and will never be truly complete.

Improved task organization, in particular, would certainly assist with the "boredom" issue, and help particularly with nonfunctional requirements.

The other big problem is the lack of social pressure to conform in online environments (ex. decision making, showing up). There can be an effort to use more interpersonal means of communication, though when I've tried it in the past, people have been quite evasive of anything that introduces social pressures.


Post your comment