Introduction

As brainstorming over an idea gets more collaboration and the idea develops into some increased complexity, we can change its status to "ongoing" and move it to this wiki area and template.

Idea: 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.

• Edit by Effenberg: If possible, I'd like to:

  • Reach a consensus with you guys on what this wiki will be. I feel like the current project is very broad.Will it be a long-term project to develop full documentation on Ubuntu? A comprehensive documentation targeted only at testers? Which minimum skills level does it expects (newbie, ordinary user, intermediate, advanced)? Or is it focused at transforming every new Ubuntu user into a tester?
  • Should we focus immediately in topics targeted at our current members (intermediate) and, with time, expand it to be more comprehensive? Or should we go for total beginners (considering current recruitment efforts may bring in users with no knowledge on Ubuntu)?
  • Establish a roadmap: Ex: Up to QQ Alpha, Up to QQ Beta, RR+. What do we accomplish here in the tester wiki in medium and long term?

  • Make a public announcement, asking members and non-members to contribute, but now saying exactly what they would have to do (topics, etc) effenberg0x0 2012-03-31 15:44:12

  • I have moved Grahammechanical's comments to the top of the Brainstorming list, given it's relevance. We'll make that happen ASAP.
  • Regarding the tester-wiki: Do you agree on creating a roadmap? Ex:
    • Now and up to QQ Alpha 1:
      • Insert all topics we feel it should have in the future, if it was a very complete and comprehensive documentation targeted at any user profile.
      • Agree on and organize such topics order.
      • Define most important topics that can help intermediate users to operate as testers.
      • Develop these topics.
    • QQ Alpha 1 to QQ Beta 1:
      • Define most important topics that can help new users to operate as testers.
      • Develop these topics.
    • QQ Beta 1 to QQ Final:
      • Define most important topics that can help advanced users to operate as testers.
      • Develop these topics.
  • Does this makes sense to you guys? If we have target / topics / deadline defined, we can:
    • Browse Ubuntu Community DOC and UF Tutorial Writers of such subjects/topics, ask them to join/contribute, use/improve their work (keeping reference and acknowledgement to original article).

    • Identify subjects/topics we'll need to ask the community/our members for help. -- effenberg0x0 2012-04-02 05:36:15

  From Ventrical

  • I think we have most of the bases covered here Effenberg. I think that we do not want to go too far and away from the topic of a simple tester wiki but if members want to contribute comprehensive Q&A, links and interlinking with other teams then let them take that up. I'm hope I'm not trying to sound like a broken record here but lets continue to keep this simple. So far (IMHO) I think that the wiki overall has been successful considering that only a handful of the tireless few have contributed to the wiki-page.

We have to continue to include context for both the highly technical and new_users. Even mid-range users may find somthing here. I would not be too overly enthusiastic in recruiting ITs from Canonical or other established Ubuntu Help Places because those persons are set in their ways. They have found a formula that works for them. Some of them are willing to share it. Some are not. We have to respect both, pro or con.

Ubuntu Evasion:

• Yes.. I can see this in many forms. Some end_users want no part of the bureaucracy and so they will continue to just duck. As for bugs (legacy nautilus bugs for example), well .. just look how we had to create a firestorm over CCSM to get any action done on that. I do not think it is part of our format to motivate developers, however, we can shame them with our bug reports , and , if that is what it takes to get them off of their a$$es then so be it Lets continue to declare our assumptions and document our work as best as we can. If we set too stringent of deadlines for other members then that may scare them away. I'm not sure where I read .. 'when is stops becomming fun ??' then what ?

I would say keep soldiering on. So far you have crystalized a very novel approach in taking a new look at the Q&A process. We have to keep illuminating the bugs and the pittfalls and highlighting the bonuses and benefits. twocamels

• Contact: Ventrical