Meego Wiki
Views

Quality/Getting started

From MeeGo wiki
< Quality(Difference between revisions)
Jump to: navigation, search
m (Fixing wiki links)
 
(8 intermediate revisions not shown)
Line 1: Line 1:
 +
= Getting started with contributing to MeeGo QA =
 +
There are a lot of ways for you to become part of MeeGo quality team, no matter you are technical person or not.
There are a lot of ways for you to become part of MeeGo quality team, no matter you are technical person or not.
-
* Try our daily build
+
* '''Try our daily build'''
-
MeeGo release engineers are producing in-development daily builds, which are available [http://repo.meego.com/MeeGo/snapshots/testing/ HERE]
+
** MeeGo release engineers are producing in-development daily builds, which are available [http://repo.meego.com/MeeGo/snapshots/stable/ HERE]. By trying these builds, you will get the opportunity to enjoy latest fancy features, although you will also get chance to spot new issues as a side effect. Daily builds are not targeted for everyone, as many features may not be fully functional and regressions may happen, but your feedback for them would be very helpful to improve the quality of our releases. If it sounds too scary for you to try daily builds, you could pick up our [http://repo.meego.com/MeeGo/releases/ stable releases] by providing same types of feedback.
 +
** You could feedback to us by reporting bugs @ https://bugs.meego.com, or sending emails to  [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list].
 +
 
 +
* '''Help out one of our [[Quality#Projects|quality teams for projects]]'''
 +
** If you have special interest or expertise in one of our projects, you are welcomed to help corresponding quality team to contribute in executing existing test cases, developing new test cases, reporting and following up bugs etc.
 +
 
 +
* '''Participate in QA tools development activities'''
 +
** MeeGo QA tools team is developing and maintaining a bunch of [[Quality/QA-tools|tools for quality assurance]]. You are welcomed to contribute in [[Quality/QA_tools_development|QA tools development activities]].
 +
 
 +
* '''Contribute in sys-debug activities to root cause bugs and assign them to right package'''
 +
** sys-debug activities are meaningful in facilitating bug fixes since a number of bugs especially system level bugs could be fixed more efficiently if they could be analyzed first to decide the guilty package so that right owner could be assigned the bug and work on it. The details of sys-debug process has been defined [[Quality/SysDebug|here]].

Latest revision as of 04:45, 8 August 2011

Getting started with contributing to MeeGo QA

There are a lot of ways for you to become part of MeeGo quality team, no matter you are technical person or not.

  • Try our daily build
    • MeeGo release engineers are producing in-development daily builds, which are available HERE. By trying these builds, you will get the opportunity to enjoy latest fancy features, although you will also get chance to spot new issues as a side effect. Daily builds are not targeted for everyone, as many features may not be fully functional and regressions may happen, but your feedback for them would be very helpful to improve the quality of our releases. If it sounds too scary for you to try daily builds, you could pick up our stable releases by providing same types of feedback.
    • You could feedback to us by reporting bugs @ https://bugs.meego.com, or sending emails to meego-qa@lists.meego.com mailing list.
  • Help out one of our quality teams for projects
    • If you have special interest or expertise in one of our projects, you are welcomed to help corresponding quality team to contribute in executing existing test cases, developing new test cases, reporting and following up bugs etc.
  • Contribute in sys-debug activities to root cause bugs and assign them to right package
    • sys-debug activities are meaningful in facilitating bug fixes since a number of bugs especially system level bugs could be fixed more efficiently if they could be analyzed first to decide the guilty package so that right owner could be assigned the bug and work on it. The details of sys-debug process has been defined here.
Personal tools