Introduction

The goal of this section is to collaboratively draft ideas that can enhance U+1 performance as a team. Our main goals are:

• Recruit more members;
• Retain members;
• Getting members involved into team activities (technical, organisational);
• Improving our communication with other Ubuntu teams, groups and users;
• Improving our current resources (wiki, FAQ, forum, IRC, tools, Launchpad, etc);
• Improving our technical processes (testing methods: Procedures, tools, automation, etc);
• Improving our management processes;

Mostly any coherent idea fits one of these goals. Idealy, as ideas are added to this section, other users can edit and improve them, turning thoughts and ambitions into mature projects.

Please add @SIG@ after your comment, so we can keep track of contributors. When the page is saved, this macro expands to your login and timestamp.

Ideas

Short-Term (up to '''QQ''' Alpha 1)

Automate diff between daily builds

• Goal: Make testing easier

• Description: If we automate diff on Daily Build t=0 & t=t-1 (and that is ridiculously easy), add the changelog (if any provided), and auto-post that to a page in our Wiki via script+editmoin (pretty much doable), it will be clear for our testers what they should give priority (test/stress-test). New bugs reported at the forum will potentially related to last updates and we will be able to associate bug to update easier. Bug reports would also be easier (package/update would be easier to detect).

• Why not just use the changelog?: BY diffing ISOs, we will be able to see all changes in detail, including those to the content of config files, for example.

• Contact: Effenberg0x0

Investigate "Problems Lifecycle" by cprofitt

• Goal: Smart / Better QA - A realistic approach to how QA influences adoption

• Description: Verify how to adopt cprofitt concept in U+1/QA structure. Check https://wiki.ubuntu.com/MeetingLogs/devweek1201/ProblemLifecycle and http://ftbeowulf.files.wordpress.com/2011/11/ubuntu-problem2.png

• Contact: Effenberg0x0

Community Building Specs

• Goal: Convert our experience with U+1, the problems, challenges, results, feedback, etc into a detailed specification

• Description: There has been growing interest in Community Building, but there's no proper / complete set of guiding docs, specs, etc. Can we try to create some generic specification, that can be improved / replicated by other projects? Also formalize the "inter-media" Ubuntu idea as a Community Integration / empowering tool.

• Contact: Effenberg0x0

You+1 Initiative

• Goal: Getting more people involved

• Description: Select one Ubuntu user that is not a current member but shows interest in technical aspects of Ubuntu (there are plenty of them on IRC, UbuntuForums, your university, etc). Invite them for an event in IRC in which current members will present the team, its activities, goals, relevance of the work, examples, etc. A portion of these users may potentially develop some interest in joining the team.

• Contact: Effenberg0x0

Map members hardware profiles and testing preferences

• Goal: Assess our infrastructure and define our testing capacity

• Description: Create table on wiki where registered members can fill in the hardware specs they will make available for testing. Not all members will accept to do all types of tests (i.e. Ubuntu Flavors). Identify what members are willing to test, their preferences and interest.

• Contact: Effenberg0x0

Ask members what we can do to trigger their motivation to get involved. Evaluate this regularly

• Goal: Improve members commitment

• Description: Communities fail for lack of interest and involvement of their members. But they also never ask what are these users needs, problems, expectations, frustrations, what triggers them, what they love to do, what they hate to do. New Role: Team Staff Manager

• Contact: Effenberg0x0

U+1 Tools

• Goal: Working smarter not harder

• Description: Take advantage of currently existing QATeam tools, develop and customise other tools aimed at performing boring tasks faster and automatically: From download / sync and burn of daily ISO, to Testing Automation. Pre-requisite: Identify members technical skills.

• Contact: Effenberg0x0

Inverting the game

• Goal: Get QA members to U+1

• Description: What if we invert the game completely and bring QA members to U+1? Can we provide them with a more friendly and motivating environment, thus obtaining valuable and experienced contributors? In the end, Ubuntu is benefited in the same way.

• Contact: Effenberg0x0

Develop alliances with other testing teams

• Goal: Increase user-base, learn from other testing communities

• Description: It sounds beneficial to U+1 and other testing-teams to meet, compare methods, results, share each other's environment, partner on projects, etc. It would prepare and empower testing groups to upcoming changes in the QA structure.

• Contact: Effenberg0x0

Make testers wiki easy

• Goal: Making it easier for new members to understand technical concepts, retain members

• Description: Ventrical made a good point with this Idea. We should always review our work to make sure it can be used and understood by any team member and user. It might be impossible to make it accessible to all users (some have absolutely no skills, interest or will to read and learn, but we must focus on the people, no matter their skill level, that *are* interested.

• Edit by grahammechanical: We need to refute a common view that new users have no place using the development branch. Contrary to the warnings that some give the sky does not fall in when a new user downloads and installs the development branch. Ubuntu is designed for new users. If new users do not try and test Ubuntu how will the designers know that their ideas have value to the target audience - new users. Emphasise the safe way to try and test. Explain in simple terms.

• Edit by Ventrical: The North American economy has created an environment where older PC hardware has become available for greatly reduced prices. Therefor, more and more basement and garage PC builders are becoming more commonplace. This means that seniors and younger persons now have an opportunity to have cheaply obtained back-up PC systems and those persons would be more willing to test Ubuntu freely, being that the opportunities for acquiring extra PC hardwares are ever growing. This phenomenon is also happening in the factory direct outlet markets and so having a back-up tester PC is pretty well the norm in more metropolitan cities in Canada and the U.S. So I am in agreement with grahammechanical to some extent, but although having a backup PC may not be a prerequisite it sure is helpful in the testing procedure.

• Edit by Effenberg: I totally agree with both. Lately I've been trying to think exactly what our responsibilities are, as a team involved in the quality/testing aspect of Ubuntu, and what they are not. We cannot embrace the world and step over other areas, like documentation, support, etc (and we don't have the resources to do that even if we wanted to). But we must set solid and right structures now, point the team strategy in the right direction, so that the team evolves in the right way. It came to me that we have to focus not on better testing, better support, but a better Ubuntu through better testers. What I mean is that we must explore activities that cause better Ubuntu software to be released, despite any legacy procedures and processes that are associated with testing and QA. As better software is released, the workload on testing, support (forum, IRC), the need for documentation and maintaining teams and people for keeping it up to date, etc decreases - and so does Ubuntu evasion. I don't think current QA testing methods are smart, as I mentioned here. I think we need to focus on our team, our members, our structure, to develop a high-performance team, which will effectively think of ways for smarter testing / smarter relationship to devs, so bugs get fixed and Ubuntu becomes better. Please have a look at the "Mentoring" and "Problem Lifecycle" (from cprofitt) ideas in this page so you see where I'm coming from. Trying to summarize (I'm obviously still not 100% on these ideas, which is why I appreciate input so much): There's a difference between being the most efficient testing team and doing what's best for Ubuntu. I wanna make sure we never lose focus on the second alternative.

• Contact: Ventrical

Better use of ISO Downloads Server

• Goal: Make testing easier

• Description: As posted here, it became clear to me, during the Beta 2 testing sprint how confusing the current server can be for new users.I never really thought we would face problems with URLs. A lot of people had a hard time finding files, browsing the servers, understanding versions, alternate vs standard (desktop), etc in order to download them. I don't think the names of these servers and their folder structure help much:

  • The files aren't properly "CD images" anymore, considering one can burn/mount them to other ODD (DVD/BluRay), internal/external HDD, external USB/FireWire/eSata/etc device, virtual machine ODD/HDD/USB, mount to network and boot via IPX, besides burning them to a CD-ROM. Most of my contacts that tested it mentioned using USB and VMs.
  • "Desktop Releases" are not targeted at Desktops only. They can be used in any hardware: Desktops, Laptops, Servers.
  • Directory structure is not clear enough, and seeing people's problems with it is strong evidence of that.
  • Nonetheless, as I mentioned one of these days on IRC, when I Google for "Download Ubuntu Precise ISO", the first 4 hits are from cdimage.ubuntu.com. Next hits are not even at ubuntu.com domain. So, it's unquestionable this server is relevant as a first point-of-contact for many users.
• When we get to any of these links, besides the files, we see some basic introductory info at the top and one single link to wiki/BurningISOHowTo. No link to a Ubuntu support source. I believe this is not enough, it calls for a better specification:
  • Rename the server (something other than cdimage.domain, maybe simply downloads.ubuntu.com).
  • Use redirection from old to new one to not create problems for people that have coded something that uses cdimage* or have bookmarked it.
  • Rearrangement of the directory structure (a more logical tree). Its not hard to think of a more structured way of arranging the files.

  • Better introductory information (as initially brought up by Graham last week), pointing at least one *.ubuntu.com source for support and more detailed info. If possible, a single Wiki page from where users could advance to all forms of support (Wiki, UbuntuForums, IRC, etc).

  • Considering we are very likely to have downloads for new Ubuntu-Based devices in the future (mobile, etc), if we do nothing, this will only get more confusing.
• The U+1 Testers Wiki can achieve its aim of helping ordinary users become serious testers by supplying information in easy to understand language.

• People who wish to try out Ubuntu or who wish to install the latest Ubuntu can go to the download link at Ubuntu.com.
• People who wish to try out or install the next version of Ubuntu whilst it is under development can use one of the two download pages at cdimage.ubuntu.com.
• Those of us who wish to be serious ISO testers should go to iso.qa.ubuntu.com.

• Finding and reporting bugs is a part of seriously testing Ubuntu. In fact the QA (Quality Assurance) Team need a bug number to be associated with every report of an ISO image failing to pass the tests.
• The QA team track the improvement in the user's install experience by means of the reports submitted. For this reason U+1 should encourage cooperation with the QA team in the matter of ISO testing. - grahammechanical.

• Contact: Effenberg0x0

Medium-Term (up to '''QQ''' Beta 1)

New Role - Marketing and Communication Manager

• Goal: Publicise the team; Getting more people involved

• Description: A member will email blogs, forums managers and admins, groups of users, publicising the U+1 Team and the easy procedures for joining it.

• Contact: Effenberg0x0

Invite developers to talk about what they like to see in bug reports, how we can help them better

• Goal: Improve team efficiency

• Description: We can learn a lot from them, decrease the time bugs take to get fixed. We can publish a set of guidelines and add to our wiki.Potential New Role: Team Developers Ambassador

• Contact: Effenberg0x0

Sikuli Automation

• Goal: Train U+1 members to develop Sikuli-based automated tests

• Description: Check out The Sikuli Project and watch this 6min. video demo. We can use Sikuli to automate a lot of things in testing: From Ubuntu install to application test-cases, thus reducing the work load on testers and using our team intellectual capital in more advanced/complex and less repetitive tasks. Any person can create a Sikuli script: It requires no skills and there's no programming language syntax to learn. We can try to get devs from The Sikuli Project to join us on a live (IRC) session for basic instructions. We can work collectively on some first trials.

• Contact: Effenberg0x0

=== Long-Term (likely RR cycle) ===

Open / publicize this wiki area ("ideas") also for non-members and the larger Ubuntu community

• Goal: Improve members commitment; Recruit new members; Assign Ideas development to members

• Description: People like to brainstorm, have ideas, discuss their point of views, feel as a part of it. Let's use our current resources (Forum, IRC) to ask them to come here and insert their own Ideas. Problem: a large volume of non-sense or disorganised content may be inserted. We might need to assign someone to read through it, delete garbage and fix disorganised content.

• Edit by grahammechanical: This is a good idea but, anyone can post in Ubuntu Forums or in irc but there is a restriction on those who have Ubuntu wiki editing privileges. And it is right that this should be the case. Let me give some more thought to this idea.

• Contact: Effenberg0x0

Hardware Samples / donation, Lending. Hardware testing, certification

• Goal: Increase Ubuntu "out-of-the-box" quality by providing testers access to as much hardware as possible.

• Description: Hardware manufacturers must have some interest in using Ubuntu testing community to test their products, report bugs to proper channels, have developers fix them. This goes from chipset manufacturers to PC OEMs. While this sounds impossible for individuals, can we, as a team and with Ubuntu endorsement, request hardware samples, donations, lend equipment from manufacturers for testing? If so, how do we organize processes to handle this? Should this be done via Canonical, Ubuntu or the team? What are the legal requirements? Who would pay for equipments shipment to testers in different geographical regions?

• Contact: Effenberg0x0

Sudo Code Quick Grabber

• Goal: To have a quick sudo code grabber reference.

• Description: Insert description here

• Contact: Ventrical

Improve U+1 Wiki Landing Page

• Goal: Communicate recent changes, important notices, events better

• Description: Implement 3 "boxes" at the landing page, autofilled by MoinMoin macros (RecentUpdates): Agenda, News, Activities. Link to proper section onClick.

• Contact: Effenberg0x0

pad.ubuntu.com

• Goal: Make collaborating on content projects easier

• Description: Ubuntu Wiki does not allow for real-time collaboration. IRC is too distracting for content-oriented group work, with users joining, leaving, quiting, netsplits, lag, off-topic comments, etc. It holds up well for small sessions in invite-only or moderated channels. UbuntuForums is also not a good option: Users can't edit the orginal post. Tasks that spread through many days or weeks in which content formatting is relevant and must be preserved (such as code, documentation, etc) benefit from etherpad. It's not clear if teams in general can use pad.ubuntu.com to create a team pad and team projects' pads under it. It could be a great resource for testers.

• Contact: Effenberg0x0

Teaming / Mentoring

• Goal: Improve quality of testing / team efficiency / reduce workload

• Description: There seem two types of Ubuntu users: Those that have no or poor skills and those that, having more experience jump to development. It's becoming increasingly hard to find skilled users, or users that are willing to learn, and recruit them to testing. Even basic tasks, such as testing the OS install seem hard to new users. It makes no sense for the team to have many users if they can't really test and understand Ubuntu. In order for U+1 to grow as a differentiated team, the quality of our work and skills of our members must be superior to other teams. If we do not take the responsibility of raising the bar to us, this situation will hardly change. Therefore we have a responsibility with providing knowledge and mentoring. Summary: Create a Team Education Manager role. He will work with the the Team Recruitment Manager to evaluate member's skills and experience. Unexperienced members will be assigned to a mentor in groups of two or three at most. It's a opportunity for them to learn Linux/Ubuntu fast from a more experieced user. A free Linux crash course. Aside from that, create regular (weekly?) IRC sessions in which new members will have the opportunity to learn about Ubuntu and Testing from other team members and invitees. Not onlytesting-oriented: Create a set of topics, from what is an OS and a Kernel to more specific ones. Guitara is working in the same line, evaluate the best way to collaborate. I think the hardest workload will be on developing guidelines to content and getting people to participate as mentors. It's not hard to spot new users eager for knowledge in places such as UbuntuForums. Even He-Man had a Mentor (and he was a MOTU). New testers / members might use one.

• Edit by Ventrical: In the world of malware they have what are called malware removal bootcamps as I am sure you are well aware of. In fact there are many other types of metoring/bootcamps for several different softwares. So I would then propose an Ubuntu Boot Camp and see if that can narrow down several subject matters down to just a few topics.

• Contact: Effenberg0x0

Enter Idea Name Here #2

• Goal: Make testing easier

• Description: Enter idea description

• Contact: Effenberg0x0

Enter Idea Name Here #3

• Goal: Make testing easier

• Description: Enter idea description

• Contact: Effenberg0x0