4 More days...

Martin Olsson mnemo at minimum.se
Wed Oct 17 03:48:20 UTC 2007



jdong wrote:
> If you have any other constructive solutions or suggestions, we'd be
> more than happy to hear them out. 

The existence of angrykeyboarders will become more and more painful and 
Ubuntu gets more and more users. The current system has a scalability 
problem and convincing people to stop being angrykeyboarders will fail 
because of eternal september syndrome ( 
http://en.wikipedia.org/wiki/Eternal_september ).

The best reponse to scott's e-mail would probably be to look into ways 
of making the ubuntu model more scalable. Changes to fix the model could 
be for instance improvements to launchpad (I guess Mark saw this coming 
and thus decided that it was a good idea to start building a bug tracker 
from scratch):

* do whatever it takes to enable realtime bug triage (i.e. a system that 
makes sure that each posted bug will be looked at by someone within 
24h). this will be achieved by making the triage process easy to 
understand, documented and lightweight:

	- list untriaged bugs (should be a big fat link on the
	  front page and triaging should be recognized as an
	  important way of contributing).
	- triage should involve a finite / fixed number of steps
	  such as for example:
		# assign package
		# assign quality tags (see below)

* introduce an objective "quality tags" on each bug. for example:

	- does the bug have repro steps
	- does the bug repro on all machines or just some hardware?
	- number of different users who have confirmed the repro
	- specs of machines where repros were done

		# here it would help if a user can just enter all
		  specs for all his machines in his user profile,
		  and then one the bug report there could be a
		  button that says "confirm repro steps" and then
		  a secondary form would ask "which of your machine
		  setups did you confirm the repro steps on?"

* make it easy to list bugs that are "high quality" and "unanswered".

* add a field for "estimated effort for fixing". this way a dev could 
list all the really easy bugs and fix a bunch of them in a single day 
(compare a bug like "python script prints 'failed to redirect to 
/dev/nal'" versus stuff like "I get low FPS in quake"; the first bug is 
trivial to fix while the second bug requires some serious ninja skills). 
the "estimated effort" could also be a good help for newbies looking for 
easy bugs to work on as their first ubuntu contribution.






Martin




More information about the Ubuntu-devel-discuss mailing list