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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss