The number of bugs reported every day is huge. It’s a continuous flow of problem reports, Apport crash reports, wrongly placed support requests, trolling, feature requests and distress. Heroically fighting to stem the flood is Ubuntu Bug Squad. Together with specialised bug triage teams for certain packages, like the kernel, they try to process as many useful bug reports as they can. However, there are too little triagers for too many bugs.

The current situation is not good for the people who work so hard to process all the reports; many leave the team soon after joining. It also causes relevant bugs to be lost in a sea of unprocessed or half-processed bogus bugs that clog up the system. It has been proposed before, but maybe we should once again seriously consider discouraging non-technical users from reporting bugs.

If we’d decide to do so, regular users would be kept away from the bug tracker. Only for automatically generated crash reports from Apport should be allowed, because the process is such that bogus reports rarely happen and many triage steps for this particular kind of bug can be automated. We would remove the ‘Help->Report a bug’ everywhere, including alpha releases. Links to reporting a bug should be removed from the documentation and the official sites. Launchpad could be adapted to make the ‘Report a bug’ button less obvious.

All this should lead to less bug reports and a higher average quality of the reports. If we focus only on the technically capable and interested users, then we’d have less clueless reports. It would save the time, energy and motivation of the bug triagers, which could then focus on making sure every bug that would be reported, would be processed quickly.

However, we should not forget that one of the things Ubuntu often is credited for is the large amount of bugs forwarded to upstream. Furthermore, an even more important argument in favour of bug reporting for the masses, is the fact that technical users use their computer different than non-technical users. They might miss bugs that non-technical users do encounter or see no problem in a feature of the system that is terribly confusing for non-technical users.

Limiting bug reporting would deprive us of this and that seems sufficiently bad to me to doubt whether we should limit bug reporting at all. I really don’t know what’d be the best. Making it harder to report bugs would make managing the bugs easier, but wouldn’t that also make the bugs we manage worth less? What do you, oh dear reader, think?

One could argue that Americans—no, I’m not going to write USanians—derive a large advantage from the fact that the default locale is their English variant. All software is understandable for them right from the beginning. They never have to wait for translations. However, in this piece I would like to argue that actually it is a disadvantage.

The Disadvantage

Why would it be a disadvantage to Americans that all software automatically suits their customs and follows their local quirks? Well, for that I would like to do a game of compare and contrast. Mostly contrast. You see, the US English strings are the only texts written by the developers themselves.

Development attracts people who like to develop, not people who like to write. They do not necessarily come from the United States, often are not native English speakers and many of them can’t see the use of arguing about -ize vs -ise, or have own opinions about it. The consequence is that the US English strings are written by people whose primary interest is writing code, not human language. This is detrimental to the quality of the texts, the suitability of the chosen phrases and spelling and grammar in general.

Translation teams, however, attract people who are interested in language. In the world of perfect localisation, all typography nuts, grammar enthusiasts and spelling bees will join together to form a team with Super Language Powers. This means that the people who will write the text you see every day on your computer are fond of language, know how to use it and have experience to say it, if you speak any language or dialect other than US English.

The Consequences

All languages—except US English—have a corrective filter between the developer’s work and the end-user. There is one community that oversees all use of language in the product. Translation teams often work with word lists, style guides and selection of contributors based on their quality. This allows them to guarantee quality, make sure that all text on the system follows the same conventions and warrant consistency across the desktop. You can correct for overuse or underuse of capitalisation, distinct between the computer and user in events by using different verb conjugations and so on.

Consistency is an important issue. For example, a computer can have a screen, a display and a view. These words are near synonyms, but the X server uses them to distinguish between three different things. It is hard enough for a user to understand what the system is talking about already, it becomes even harder when words can have different meanings in different applications. When there is no central organisation of the terminology, this does happen. Translators could correct for this by adapting the translations to the context, but Americans are out of luck.

There are no people looking after the typography, grammar, capital use and readability of US English. But there is more to localisation: translation teams also make sure that the system is using the correct date format, currency, decimal delimiter and so on. Each country has its own conventions here. No one has the job of nitpicking about the American conventions, so they’re missing a watchful eye here as well.

The result is that the US English desktop can often be inconsistent in style, word choice and spelling. This makes our product less appealing to Americans and to other people using the US English version. If we want to pursue perfection, we should not miss this out.

It has also consequences for the translations. The translations are translations of the original English texts. Although I did say earlier that translators can correct for inconsistency and bad wording, they don’t always do. It is a lot of work to manually check the context of each and every string, many translators just stick to translating every word with the same phrase. Badly used capitals and dots will often find their way into translations as well. Vague US English results in vague translations.

Solutions?

Improving the quality of US English will mean large improvements for all languages if it is done properly, by sending patches with corrections to the developers. I am convinced that we need an American ‘localisation team’, consisting of all American typography nuts, grammar enthusiasts and spelling bees who want to contribute to Ubuntu and FOSS in general. They could work together with other projects to establish conventions and methodically go through all applications to check whether they comply with these conventions.

We cannot ask from all the localisers to understand programming language and patching systems. However, with the current state of technology, I am afraid that writing patches directly for the code is the only option. In the long term, something like a POT editor and a reverse POT generator could improve things.

It would also require infrastructure. Many languages have project-agnostic communities for translation in FOSS that provide various language-related services; examples are the French Traduc and the Dutch OpenTaal. These relations are often not formalised, but they are really helpful in making sure everyone is somewhat following similar rules. As part of FreeDesktop an American initiative could be started, which could keep a list of the standard meanings and uses of words.

The solutions above are just ideas for ways to deal with a problem that we should give much more attention than we have done so far. Admittedly, it is easy for me to talk from the sideline, knowing that I—being a native speaker of the Dutch language, not of US English—will never be doing much of the work I propose. But I do hope that some people will be inspired by this piece and do something with it.

Those poor Americans deserve localisation too!

Something a really like is brainstorming about features that would make Ubuntu even more awesome. Even though we already have Brainstorm and there is a UDS twice a year, I think a monthly session with experts would be something very meaningful. Ideas get a lot better when you discuss them with a group.

I proposed two solutions at Brainstorm, and I like both.
Solution 1:

Have a BoF session on IRC every month. People from all over the community can brainstorm the most daring things and if they like it, propose it at Brainstorm/start working on it/create a blueprint/propose it for the UDS. I think the whole community should be allowed to join, but there should at least be some experts there to comment on ideas.

Have a blog meme after every new release where you write about the things you miss in Ubuntu or the things you think that would make Ubuntua absolutely irresistible. This isn’t something that can be forces, it has to be done voluntarily by the community members.

Something I find irritating is that my favourite MMORPG Regnum Online has to be ‘installed’ inside a directory inside my home directory because the client NEEDS to update the resources regularry, and for that, of course, my user needs writing permissions. However, if I want to let another user play it, I have to chmod the directory to 777, make sure my home dir can be read by all other users and create a symlink inside to other user’s home directory.

What if there would be a central directory for all system-writable stuff. Not only game resources, but also themes and extensions for programs like Pidgin. This way everyone can access resources that else would be duplicated.

Of course these contents should be handled with care and i’s probably not suitable for all programs. There shouldn’t be any executables in that directory.
However, I do think it could improve certain programs a lot AND would make Linux a little bit more attractable for the large — yes, maybe closed too — companies and game developers.

What is it?

A website where new features, programs, etc are collected. It shows an overview of all parts of the project within the Ubuntu ecosphere.

What does it do?

• List the branches and shows their status
• List the Launchpad specification(s) and its/their status(es)
• List the required packages — even if they’re not created yet — and shows their status
• Register the necessary entries in the QA test tracker and watch the progress of the testing
• Show the contributors and list their responsibilities
• Link to/include the wiki page of the specification
• Show the due date and warn the contributors when they’re too late
• Support dependencies: e.g. when person X needs to wait until package Z has been packaged by person Y, he gets an email as soon as person Y has done his/her part

If you like the idea, please vote for it! If you’ve got feedback, please comment. Thanks.

Maybe you’ve already heard about the Dutch plans to make open standards almost mandatory for the (semi-)governmental organizations.
Although the regulation was already effective as from the first of April 2008, recently there have been some developments. Now the plans have been approved by the European Commission. Furthermore, the use of open standards is now even closer to mandatory; if a (semi-)governmental organization wants to use a closed standard now, they have to have a very good justification. Also see the Dutch announcement at the website of the Department of Economic Affairs: Instructies rond gebruik open standaarden.

The government also created a website called Forum Standaardisatie, where information is published that could help the differentment parts of the government to choose the right standard. You can find the English version at http://www.forumstandaardisatie.nl/english/, but keep in mind that most of the data is in Dutch.

Why did I create an idea at Brainstorm for this? When the costs of a tender of a (semi-)governmental organization in the EU exceeds a certain border, the organization HAS to allow all companies in the EU to fulfil the order. The tender is published with the European tender system at http://ted.europa.eu/ and all companies in Europe can send their offer.

Now a large part of the Dutch government probably is going to switch to open standards, there will probably a lot of tenders about switching. If Canonical would try to participate here, Ubuntu could be the OS running parts of our government! Compability shouldn’t be a problem since open standards are required. If Microsoft won’t support them properly, I have no doubt that Neelie Kroes would do something to that…

However, Ubuntu should also get some more fame in the Netherlands so the people in charge of picking the candidate for the tender know what they can choose. Here lies a task for Ubuntu NL. I think it would be a good idea to watch the media carefully and try to fix mistakes in case they make mistakes and notice them when there is a major Ubuntu event, like a new release or maybe even the UDS.

I hope this suggestion would at least be considered since it could be the change for Linux to get a lot of new users. Another plus would be that being used by a government increased the will to support you.

Lately I got more and more the feeling that hardware vendors are more and more extending their support for Linux.

However, it’s still far from perfect and not all companies have muche experience with interacting with the Linux community. Some companies still seem to be hestitant to be kind to Linux-users.

If we could show them that their products really are used by Linux-users and what products cause the most problems, it could encourage them to improve the Linux support.

What I suggested at Brainstorm is to start, in cooperation with other distributions, hardware vendors and maybe upstream projects, a survey to collect data about the hardware that is used the most frequently and what hardware causes the most problems.

For example: I’m using Compiz-Fusion, Emerald and AWN. Because of this I’ve got a list of configuration utilities for appearance and graphics:

• Awn manager
• CompizConfig Settings Manager
• Screensaver
• Screenresolution
• gnome-appearance-properties
• GDM theme

The special effects tab of the gnome-appearance-properties program is useless now because I’m using custom settings.

Although I do appreciate the work both the Ubuntu and GNOME developers did to make configuration easier and I have to say that a lot has improved, like the gnome-appearance-properties program bundling all different theme programs. However, it can still become a lot better.

At least some configuration utilities should be looked at to see if they could be merged with others. But I think that some more fundamental changes could even make it better. What about a pluggable system that divides all configuration tools into some basic categories. The ‘System’ menu would contain these categories in its root and all programs like Synaptic would be moved to Application->System tools for the sake of consistency.
Each category would have its own program based on the same framework to make things consistent. When a new configuration tool is installed it would appear as some kind of tab. All settings that require root privileges can be handled with policykit.

This would just make browsing the tools easier, but doesn’t solve the issues like the enabling of Compiz. There is no other solution for this than just going by all settings and see how this could be improved.

There is also an idea at Brainstorm suggesting something similar:

It already has quite a lot of votes, but giving it more attention can’t hurt.

Again, I’m not affilated with GNOME. I don’t know if this is something GNOME developers would like, I don’t even know if they’re ever going to read this. But maybe they’re already working on something like this! I don’t know.
What I do know is that this issue is, at least in my eyes, one of the weakest parts of GNOME. It deserves some attention. I hope I this post helps a bit.

An interesting point was raised during the discussion that took place at the mailist; someone suggested to integrate the volunteer pool that was suggested earlier at Brainstorm in the Ubuntu Wanted site. This would give some great opportunities, e.g. the user could be notified when a role he’s interested in would be placed. This wasn’t the first time someone suggested it, but now I finally agreed with the suggestion. However, I don’t want to make such a radical change without asking other people first. Although I’ve offered to lead this project, I don’t want to be a dictator. I’ve send mails to Pasto, the person that suggestion the volunteer pool, and someone else that offered Pasto his help with coding.

I’ve brainstormed a bit about this site in one of the mails I sent to the ubuntu-website mailist. I’d also like to get some feedback from more people than just the people at the mailist — there are not many people subscribed — so I want to ask you to look at this passage I copied out of my email and tell me what you think of it and the whole idea of integrating the two ideas into one site. Feedback about the Ubuntu Wanted site itself is also very, very welcome.

(…)
I’m now
thinking out loud, so please say it when you don’t agree.
The user only ends up in the volunteer pool when (s)he creates/activates
his/her profile. Than a status can be set showing how eagerly the user
is looking for roles. At the profile are the tasks shown that the user
has fulfilled or is fulfilling within the Ubuntu Community and outside.
Experience and knowledge of software and programming languages should
also be visible.(Should the level of education and age also be visible?)
Other users can write testimonials about the user. However, how are we
going to display experience? Will it be (semi-)automated like Ohloh, by
checkboxes or by text? Should it contain links to other profiles? I
think there should be some automated forms for Ohloh and SourceForge
profiles(and more) profiles and a text area to tell about the current
and past roles. Programming languages can be done with checkboxes,
experience with drop-downboxes.
I think the profile should also have a text area where the user can
tell something about him-/herself.

Getting a volunteer pool would also have the advantage that with certain
tasks, the users that might be interested could get mailed when
something an interesting role would be posted. Especially if the user
could tell the system he’d be interested in a position in a certain team.
(…)

Leave a comment here, or mail me using the contact form. Participating in the discussion at the mailist or contacting me(qense) at #ubuntu-website @ freenode is also good, of course. In fact, I’d encourage you to contribute to the mailist when you’re interested to help, so people other than me can participate.

Thanks in advance.

After I read an maillist entry from dholbach and the blog post it was pointing to(The Harvest Season has begun!) I thought again of an idea I already wanted to add to Brainstorm before, but never did. The idea was to integrate the program ohcount used at Ohloh to analyse projects.

Keeping your project in good shape is vital for the results. But in order to do that, you have to be able to keep track of the shape. Currently Launchpad doesn’t provide a tool to do so. The Ubuntu QA team uses several homebrew tools to do so, but it would be beter if this would be integrated within Launchpad and be available to projects outside Ubuntu. When Harvest would be added next to ohloh, keeping track of bugs and patches would be made a lot easier, so submitted patches won’t lie around for decades before someone has a look at them.

The functionality of both projects could help project managers and contributors a lot when they need information and I think that the quality of code could really improve.

Soon after I had posted the idea jcastro told me that dholbach had said to him that persia was probably interested in this idea. After I pinged persia I indeed got a nice email from him.

He liked the idea, but also had some concerns. The main concern was that it could splinter communication. Most teams communicate mainly on their IRC channel and with their mailists. If suddenly all new tasks would appear on a separate website, things could become very confusing for team members. They don’t know where to look. And discussions about applicants would take place at more than one place. You’d have the mailist, but also the wanted site.
This problem could be solved by letting the wanted website mail all new jobs and applications to the mailist of the team. A bot can place the reactions in the comment tree at the website.

Another part of his concern was that such a website could let it look like you can only have one job/task within the Ubuntu Community. However, there’s no rule telling you how many jobs/tasks you can have. If a wanted site would be created, it should be made very clear that there’s no limit. For example, calling the ‘items’ at the wanted site ‘jobs’ would probably make it sound to big. I think tasks would be better, but that’s something that should be defined by people that are experienced with things like this.

It should also be very clear what is allowed at the site and who can post. Some people would like to use it also for jobs outside the Ubuntu Community, e.g. a system manger for the server of the local football club, but I think it should be restricted for tasks within the Community. More items would cause too much noise making it harder to find the task you’ve always dreamed of doing. I think it would be the best to give each team its own category and create two types of tasks: dynamic(team leader, maintainer of package X) and static(bug triager, MOTU). These different types should be easily distinguishable. As authentication method the developers can use OpenID, since LP is an OpenID provider. I’m not sure if you can also request a list of teams the user is member of, but I’m asking it right now at #launchpad and will update this post when I’ve got the answer.

The biggest problem in my eyes is how to determine who is allowed to place items. Just the team administrators? Anyone? Or just the wanted site crew? The best option, according to me, would be to allow all team administrators to post ideas. But from what teams? There are loads of teams registered at Launchpad and not all of them have something to do with Ubuntu. And teams like Ubuntu Smokers don’t really need to place items. I think(Wow! I really think a lot!) that it would be the best to let the team administrators request access. When they’re approved an admin adds them to a list against which the results from the Launchpad teams query are checked.

At brainstorm someone also suggested to allow mentors to be assigned to tasks, which is a great idea according to me. However, are there enough volunteers who are willing to help newcomers?

A last question is which programming language should be used. Most Ubuntu websites seem to use Python and it would surely be a good idea to use it, since integration wit LP would be a lot easier. So I’d vote for Python, even though I’m not very familiar with the language.

Please post your feedback!

EDIT: I’ve created a Blueprint: Blueprint: “Ubuntu Wanted Site”

It’s about keeping track of your system and cleaning it every once in a while. All files that aren’t registered, except user data, will be removed. I’ve explained this quite detailed in the idea, so please read it to get a better idea of the idea.

I hope it can be created at all, since the idea sounds quite complex to me, but there are already some programs around that have similar functionality. Maybe they can borrow code from that.

Something that probably can’t be used as a base, since it uses transcripts to keep track of the files that need to be monitored, while I suggested to use the .deb files themselves, but that did give me the idea is Radmind. It’s a piece of software we’re using to manage the iMac lab in at school, which is used for graphics. Our system administrator is afraid of anything that isn’t made in Redmond, or supported by the company from that place, so the pupils that work on the school website also manage the iMacs. Radmind makes sure that all systems are identical and makes it easier to deploy updates and software. It’s a really nice tool and OpenSource! It has a client for Windows(beta), Mac and Linux and the server is available for Mac and Linux. You install one client and create a negative and positive transcript. A negative transscript is used to make sure certain directories exist and have the right permissions. E.g. your home directory and system specific settings. A positive transcript is used to make sure files have the same content. After you’ve created those two transcripts, uploaded them to the server, accept them and add them to the control file(Unfortunately, only the Mac server has a GUI for this, Linux not even a CLI tool.) and you can run the Radmind Update functionality on every client. Now all clients will be the same. All clients can be the master client. If you install new software you have to make a new transcript file. If you forgot to that, the changes will be reverted next update. The new transcript file will only contain the things that changed between the current situation and the last transcript file. It has to be accepted again.

OK, lets go back to Brainstorm. It has been updated lately( Assigning ideas to projects, tags, and user contact ) and now supports, like the title already says, tags, user contact and my favourite: assigning to projects. Under the small text in the top of an idea you’ll now see other small text telling you to which project this idea is assigned. This allows further categorization and makes it easier for project managers to find ideas concerning them.

By the way, I’ve got one reaction at my post about my departure from the BugControl team! I decided to not approve it, though. Ibod Catooga was kind enough to let me know that all Asians hate me advised me to uninstall Linux and hang myself. Unfortunately for Mr/Mrs Catooga I’m not going to do the such a thing. I’m not sure if all Asians hate me, though.

It ‘s about creating a website for the Ubuntu Community where people can place temporally advertisements for things a team needs(new team leader, programmer for upstart) and infinite ads(bug triager, MOTU member). They should also of course explain how to get the ‘job’.

I was thinking who should get access to the posting functionality. Only team management? Or also people who’ve started a new project(like the Launchpad KDE Client)? What I suggest is to create different categories for every team. Only the team management of a certain team can post in their category. And one other category for new projects.

This rises the question how to get the data of the teams. I’m not familiar with the Launchpad API(does there even exist one) for teams. I think it would be the best idea to use OpenID and request the teams from Launchpad to check to what team they should get management access. But does Launchpad already support that?

Anyway, another thing that should be addressed is how it should be written. PHP or Python? And should an already existing platform be used to base it on or something completely new? I suggest to use an already existing piece of software and adapt it to our needs.

However, the idea has just got 35 ideas at the moment, so more are needed. Please vote for the idea and leave some feedback!

(PS: I posted exact the same post at Ubuntuforums.org, but I’d like to get as much feedback and attention as possible. )

"Hello,

A while ago I joined the Ubuntu Youth team and asked what they were
doing. I was told
that the only purpose yet of the team was the #ubuntu-youth IRC
channel where young
Ubuntu users could gather and communicate. That didn't sound much to
me so I though of some ideas. Unfortunately I never got a real
response to them.

When I rethought and extended those ideas I realized that they were
also suitable for the whole community. It's meant to educate new
people to Ubuntu how to use it, but also learn people new to the
Ubuntu community how to participate. I mostly thought of complete
newbies to the kind of process, but I think we should (if it would be
implemented of course  ) make certain parts also usable for people
coming from other projects.

A thing I suggested was to provide the young people coming to the team
education. The team can help young Ubuntu users find their place in
the community(mentors? guides?) and learn them about their 'work'. The
current lessons are also a bit technical, which I personally like, but
it's probably not suitable for the a lot of people new to Ubuntu/Linux.
So I suggest to also provide lessons explaining how to use
OpenOffice.org, use educational software, import photos from the
digital camera and organize their music library(and other things
people want to do with their computer(suggestions needed)).
This requires an easier way to find the team and take part in the
lessons because not all people can or want to learn how to use IRC and
look up the #ubuntu-classroom channel(although I though people are
already working on this. Is that true?).
Maybe an entry at the Ubuntu start page, in the Ubuntu Help and at the
yet-to-be-written/accepted/designed Ubuntu start centre would really
help.

Another thing I would like for people new to the community, and which
is already done by the MOTU, is mentoring. Every person asks the team
for a mentor after (s)he has done a test/read a guide to determine
what part of Ubuntu (s)he wants to participate in and gets(if there's
place/need of help) a mentor specialized in that part of the
community. The mentor, who can have more than one pupil of course,
helps finding his/her pupil the right 'job' and learns him/her how to
do it properly. The mentor will guide the pupil in the community until
the pupil finds (s)he doesn't need the mentor anymore or, in the bad
case, when the mentor doesn't have time to do it anymore or doesn't
want to help the pupil anymore.

I thought of this resources: one 'council' team to manage the whole
'project', one mentor team, a pupil team, wiki pages, a mailist(one
for appliance, one for management) and an IRC channel.

OK, this was the suggestion. I've probably forgot a lot of things,
please correct me where I made mistakes and give your feedback. Maybe
I've sounded a bit rude because I don't speak native English or forgot
the implications certain things have. I'm sorry for that.

Sense Hofstede
<http://www.qense.nl/>
<https://launchpad.net/~qense>
<https://wiki.ubuntu.com/Qense>

PS: It's just an idea. I want to suggest something, I don't try to
enforce anything to anyone, although I may sound so somewhere. Please
tell me where/if I do so."

OK, I may have been a bit to careful with the anti-flame disclaimer, like I call it, but it is what I think and I’ve experienced once before an attack after a suggestion. After that I’ve been careful.

Of course the LoCo teams should also get involved, because English isn’t the only language in the world. Maybe #ubuntu-classroom-nl channels?

I’m really curious what people think of this idea. Please leave a comment or reply to the mailist. I do want to help with the project, but I have to warn that I don’t have much support experience, so I think other people are more suitable for leading the whole thing. I think the whole NUN team should be extended, rather than replaced by a new team. But I’m not familiar with that team and the only thing that I know that they’re currently doing is maintaining the main support channels. (Apologizes if I don’t fully recognize your hard work! )

So what do you think?

This is what he said:
“Bug-tracking/triaging is part of the social foundation of free software. However this aspect is not implemented efficiently at this time. Therefore I suggest:

Since I submit my information to hwtest and popcon anyway, this information might as well be used. I suggest

1) That I can click a box and be mailed (with some selectable probablity) when a new bug is submitted by someone with the same hardware, and for a program that I also have installed. Then I can help trying to reproduce the bug.

2) That I can keep a list of people who helped me solving my bugs, and be automatically notified (with a selectable probability) when they submit a new bug – so that I can see if I can help them back.

More advanced suggestion are

3) That I can make a prioritized list of programs that I want to be notified for new bugs in – with a probability determined by a value selected by me and modified by the goodness of match of hardware of and ‘friendness’ (see 1) and 2).

4) That company (I’m thinking of Dell of course, maybe Intel, AMD, Acer?) representatives are engaged in this scheme, and can help organize and drive the social bug-tracking around their hardware.

Best,
Anders”

I like this idea. If you’d have to give your Launchpad ID while running hwtest and the program would send the data to Launchpad and attach it to your profile you could easily gather statistics about hardware and find out if the bug that’s bugging you is already reported, saving us, the bug triagers, a lot of work. I think this can increase the number of bugs fixed and triaged and can also reduce the ammount of duplicates. And if we can get the hardware manufacturors to compete with each other about how few bugs they all have reported concerning their hardware I think this can we really good for the whole of Ubuntu!

So therefore, vote for this idea!

(A downside is that it’s probably an awful lot of work. It requires changes in hwtest, launchpad and probably the creation of a new program. Maybe worth a bounty?
To get the hardware manufacturors interested we need to get their attention. But how on earth can Linux do that?)

Something that people would immeadiatly say is that it is extremely dangerous. That’s true, very true. There would be a lot of people wanting to abuse this. Therefore such a system would need extreme seccurity. If something goes wrong the image of open-source would get a large blow.
I suggest to create a special support team that is assigned to this feature. That team needs to have a triple signed GPG key in it’s LP profile and it’s membership need to be confirmed by the owner. Having signed to Code of Conduct in such a way that it would be legally valid would also something that I’d recommend. And at registration an EULA that says that Launchpad isn’t responsible for anything that goes wrong and makes the abbusing person chargable. The tool should determine the rights of the person on the package where the problem was reported in and should just get access to that package, related programs and a terminal. If sudo should be enabled needs some serious discussion.

Adding this to Launchpad would bring the support of Ubuntu to a higher level, and make it a lot easier for people to be helped.

Please leave a comment with your thoughts about this.

Sources:

Using Launchpad accounts to manage your local ssh logins