[ros-dev] TC function description: Call for vote

[Ge van Geldorp]

One day late (I still like coding better than these administrative tasks
:-)) I call for a vote on the TC function description. The vote will run for
7 days and ends 8 Nov. I will create the vote on the forum.

I'm slightly amending the proposals to vote on, after Casper pointed out
both of the proposals would violate the (draft) constitution. In proposal A
(which gives the TC power to block a release) "the approval from a board
member" is no longer required to override the TC's decision to block a
release. In proposal B (no blocking power) the sentence "The TC has final
say over the priority of a bug. By his election, the developers and board
members have agreed to trust in his judgement related to bug priorities, and
must not hinder any legitimate efforts that the TC is attempting in order to
prioritize bugs." was dropped.

In order to preserve the full text of the proposals for our children and
grandchildren, I'm including them below so they will get archived.

This is the resolution to vote on:

Do you want to:
A) set the function description for the TC role as described below under
"Proposal A" or
B) set the function description for the TC role as described below under
"Proposal B"

Happy voting, Gé van Geldorp.

========= Proposal A =========

Mandate

The Testing Coordinator's (TC) job is to ensure continous quality releases
of ReactOS builds and to periodically verify the current status of the SVN
"HEAD" Branch in order to quickly identify regressions. The TC's job becomes
even more critical as we approach an official release, as every application
known to work in a previous release must continue working, and the fixing of
older bugs needs to be assured in order to ensure a steady stream of quality
increase between releases. The TC's tools include complete access over
Bugzilla, as well as a team of testers which respond directly to the TC.

Term

1 year renewable.

Powers

Since one of the TC's primary and most important tools is the Bugzilla
Database, the TC is granted complete administrative control over the
Database, with the power to create, delete, modify any bugs he chooses, as
well as the ability to perform administrative maintenance tools such as
adding a new revision to the databases's list, handling developer emails,
assigning bugs, etc. Due to the sensitive nature of such control, the TC
must be properly trained in the usage of the administrative interface, in
order to avoid accidental damage to the DB.

The TC has final say over the priority of a bug. The TC can decide as his
will which bugs to promote to Blocker status (thereby blocking a new
release), or to demote bugs below that status. Although the TC is
recommended to specify a reason for his judgement, his decisions should not
be the cause of endless flame wars and challenges. By his election, the
developers and board members have agreed to trust in his judgement related
to bug priorities, and must not hinder any legitimate efforts that the TC is
attempting in order to prioritize bugs. However, in the rare case where it
is clear to a majority of developers that the decision to block a release is
unwarranted, a group of no less then three developers may override the TC's
decision. Such actions should never have to happen however, and communicaton
is highly recommended in order to reach a moderated debate.

Obligations

Since the TC's job is critical to the success of ReactOS on the public
scene, as well as a smooth development environment internally, unhindered by
the constant search of 3000-revision old regressions, there are some
obligations which the TC has towards the ReactOS Team.

One of the key obligations of the TC is constant contact with the developer
team. The TC must be present in daily development activities as much as
possible, to ensure that he is constantly aware of new bugs, difficulties in
fixing some bugs, and other design or architectural decisions which might
impact the severity and/or presence of a bug or regression. This is to avoid
cases where the entire developer team is aware of a voluntary temporary
regression, but the TC knows nothign about it and blocks the release.

In order to fulfill his actual mandate, the TC is required to test the
current SVN at an acceptable pace. It is hard to give an exact number of how
many revisions can pass beteween a new test, as sometimes there can be 40
consecutive revisions that merely fix some naming, while other times, a
single revision can change everything. Therefore, it is up to the TC to be
in contact with the dev team, and also his personal judgement to determine
when a certain treshold of potentially regressive changes have been done.

Finally, the TC should have an active list of applications, tools, and
testing environments used to test the builds. He should provide this list
publically so the other members of the team can collaborate, comment on, and
potentially verify and more important duplicate results. This will be key to
allowing developers to easily fix regressions or bugs. The TC should set up
a page or alternative method of visual real-time communication showing the
current applications tested/in testing and wether any flaws have been noted.
Preferably, specific features of each application should be tested. An
example is listed below:

                                      CURRENT REV: 25000
 - Abiword
   - Menu System                                               V
   - File/Open System                                          V
   - Toolbars, docking, and other graphical elements           F -
Regression. Docking a toolbar makes it disappear
 - Regedit
   - Deleting a key                                            V
   - Creating a key                                            F - Known
bug. Creating a key cannot be done.

========= Proposal B =========

Mandate

The Testing Coordinator's (TC) job is to ensure continous quality releases
of ReactOS builds and to periodically verify the current status of the SVN
"HEAD" Branch in order to quickly identify regressions. The TC's job becomes
even more critical as we approach an official release, as every application
known to work in a previous release must continue working, and the fixing of
older bugs needs to be assured in order to ensure a steady stream of quality
increase between releases. The TC's tools include complete access over
Bugzilla, as well as a team of testers which respond directly to the TC.

Term

1 year renewable.

Powers

Since one of the TC's primary and most important tools is the Bugzilla
Database, the TC is granted complete administrative control over the
Database, with the power to create, delete, modify any bugs he chooses, as
well as the ability to perform administrative maintenance tools such as
adding a new revision to the databases's list, handling developer emails,
assigning bugs, etc. Due to the sensitive nature of such control, the TC
must be properly trained in the usage of the administrative interface, in
order to avoid accidental damage to the DB.

Obligations

Since the TC's job is critical to the success of ReactOS on the public
scene, as well as a smooth development environment internally, unhindered by
the constant search of 3000-revision old regressions, there are some
obligations which the TC has towards the ReactOS Team.

One of the key obligations of the TC is constant contact with the developer
team. The TC must be present in daily development activities as much as
possible, to ensure that he is constantly aware of new bugs, difficulties in
fixing some bugs, and other design or architectural decisions which might
impact the severity and/or presence of a bug or regression. This is to avoid
cases where the entire developer team is aware of a voluntary temporary
regression, but the TC knows nothign about it and blocks the release.

In order to fulfill his actual mandate, the TC is required to test the
current SVN at an acceptable pace. It is hard to give an exact number of how
many revisions can pass beteween a new test, as sometimes there can be 40
consecutive revisions that merely fix some naming, while other times, a
single revision can change everything. Therefore, it is up to the TC to be
in contact with the dev team, and also his personal judgement to determine
when a certain treshold of potentially regressive changes have been done.

Finally, the TC should have an active list of applications, tools, and
testing environments used to test the builds. He should provide this list
publically so the other members of the team can collaborate, comment on, and
potentially verify and more important duplicate results. This will be key to
allowing developers to easily fix regressions or bugs. The TC should set up
a page or alternative method of visual real-time communication showing the
current applications tested/in testing and wether any flaws have been noted.
Preferably, specific features of each application should be tested. An
example is listed below:

                                      CURRENT REV: 25000
 - Abiword
   - Menu System                                               V
   - File/Open System                                          V
   - Toolbars, docking, and other graphical elements           F -
Regression. Docking a toolbar makes it disappear
 - Regedit
   - Deleting a key                                            V
   - Creating a key                                            F - Known
bug. Creating a key cannot be done.