This page contains recent changes and clarifications to the component competition guidelines.

Changes to the review signup process

We have just implemented the suggestion to make the number of active reviews affect the delay incurred before a reviewer can sign up for a project. The way this works is:

1) Reviews open 12 hours after a project's registration phase starts.
2) For every active project a reviewer has, they get a cumulative delay of 6 hours (counting from the time the review opened) before they can register for a project.
3) "Active review project" is defined as a project the reviewer has registered for and for which the review phase has not finished yet.

Move to new .NET build script

As some of you noticed, we have been using the new .NET build scripts for building .NET component for one month and it works great.
You can download several current finished .NET catalog component distributions to have a look at.

Now we decide to move to new .NET build scripts which is based on MSBuild (http://msdn.microsoft.com/en-us/library/ms171452.aspx).
From now on, all the design distribution and development distribution will use these new build scripts as our standard .NET builds scripts.

You can get the new .NET build scripts package here: http://www.topcoder.com/wiki/download/attachments/23727045/dotnet_build_scripts.zip
Or you can check out them from the SVN repository: https://coder.topcoder.com/anonymous/catalog/master_builds, I have given all the SVN users the read access to this repository.

For more information about the new build scripts, please refer to: http://www.topcoder.com/wiki/display/tc/.Net+Component+Build+Process

Scorecard documentation updated

The documentation wiki pages for both design and development have been updated with the latest scorecards. Additionally, the development section now has the testing scorecards.

Unregistering from projects

In the past we have been fairly flexible in allowing unregistration from component projects, as long as a request was sent before the registration phase ended.

*Going forward, unregistrations will only be allowed for custom component projects.*All relevant information is public for generic components, and it is your responsibility to peruse it, ask any questions, and make sure you're interested in a project before signing up for it.

New competition RSS feeds

We have created RSS feeds that will allow members to sign up to be notified of available competition opportunities. We will begin to phase out the notification emails shortly, as this will become the primary means to notify competitors of available design, development, assembly, and architecture opportunities.

Component Design Opportunities

Component Development Opportunities

Application Assembly Opportunities

Application Architecture Opportunities.

Coverage Tool

TopCoder is implementing the use of Coverage Tools for all development submissions. Cobertura (http://cobertura.sourceforge.net/) will be used for Java, and nCover (http://ncover.org/site/) will be used for .NET. See below for new build scripts and instructions on how to use the coverage tool.

• To pass screening, submissions must have at least 85% line-coverage from the unit test cases.
• The new scripts will save the coverage tool report in the /log directory; please include all files in that directory in your submission.
• Submissions due on or after 01 March 2007 are required to have the coverage tools results embedded.
• While submissions due before 01 March 2007 do not require use of the coverage tool, you are highly encouraged to do so.

Cobertura instructions:

1. Download the latest cobertura.
2. Modify the build.xml for the 'codertura task definitation' part to add all the dependencies into the 'cobertura.classpath'.
3. Modify the test target to add your own instrumented sources, if you want to do coverage report for all the classes, just keep it as it is.
4. Use 'ant coveragereport' to generate the reports.

nCover instructions:

1. Download nCover 1.5.7.
2. Add a nCover_Home environment variable and point it to the installation directory of nCover.
3. Use 'nant test' to generate the tests.
4. Use 'nant ncoverreport' to generate the reports.

Using nCover with .NET 3.0:
Use nCover 1.5.7.
Set the property as such:

<property name="WCF_BASE" value="C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0"/>
<property name="ServiceModel.dll" value="${WCF_BASE}\System.ServiceModel.dll"/>

Guideline Clarifications

* Testing Protected Methods:

All methods that are exported by the component should be tested. This includes protected methods. In this light, "all public methods" in the scorecard should be interpreted to mean "all non-private methods".

* Association vs. Aggregation vs. Composition:

An association (base type) is used when any class (A) references any other class (B). In this case, this reference isn't kept as an attribute of that class, it's just that A uses B somewhere without keeping B as part of its state.

A composition is used when class A keeps a reference to class B:
1) as part of its state
2) when instances of A define the lifetime of B (B is dependent on A for it's survival).

Aggregation is used when A contains a member variable of type B, but doesn't define its lifetime.

* Copyright Notices:

Copyright notices in source code need to be correct as required by the TopCoder CheckStyle rules.

* Java 5 Enums:

When designing Java 5 components, you should use the language's built-in Enums rather than the Type Safe Enum component whenever possible (unless the requirements state otherwise). When coloring them in the class diagram, use the same color as for .NET enums.

* Diagram Titles:

The Poseidon-generated diagram titles are sufficient, there's no need to also have separate diagram titles.

* Scoring of question 1.1.1 in the design scorecard:

The component's architect will have final say on whether a design aspect addresses an existing requirement or is an enhancement. The reviewers will determine whether an enhancement is substantially useful.

* Use of overly restrictive transaction isolation settings:

Using restrictive transaction isolation settings (REPEATABLE READ, SERIALIZABLE) can have serious consequences in environments where multiple applications have to access the same database. These settings should never be used unless explicitly approved by the PM.

How the appeals process works

There are a number of misunderstandings about the appeals process that I will clarify in this post. I am also instituting a deadline for filing petitions about the appeals process.

* During the appeals phase, it is the submitter's responsibility to ensure that every appeal has all the information the reviewer needs to answer it. You should provide links to standards, forum discussions, etc. If the reviewer hasn't provided enough information in the scorecard for you to know what to appeal, you should file a petition immediately (and appeal anyway with what information you have).

* During the appeals response phase, the reviewers will reject any appeal not based on fact. Arguments on matters of opinion will be dismissed. Any appeal based on fact must be addressed thoroughly, and the reviewer must provide all the information the submitter needs to understand their decision (links, etc.)

* You may use the Contact link in the project's Online Review page to file a petition if you believe that an appeal has not been resolved correctly. Once again, only matters of fact may be appealed. Moreover, you may not file a petition against another submitter's scorecards: only your own submission's scorecards may be petitioned. Petitions must be filed promptly: we will not accept any petitions received more than 24 hours after the appeals response phase ends.

If you have concerns about a reviewer's performance at any step in the process, you may use the Contact link in Online Review to contact us.

How to become a reviewer

We are introducing new requirements for membership in the component review boards, effective immediately. These requirements affect the Java Design, Java Development, .NET Design, and .NET Development review boards. The C++ Design and Development boards will have different requirements that are listed below.

1) All reviewers must have a component history with at least 10 projects with a post-appeals review score of 85 or higher.
2) All reviewers must have at least one component with a post-appeals score of 85 or higher in the last three months.

Only projects that have been included in the reviewer's component history count towards the requirements. Projects are generally added to a component history within a day of their completion.

Existing active reviewers will be allowed to continue working, but they will be required to meet the regular requirements following this schedule:

* Existing active reviewers will be required to meet requirement 2 by August 1, 2007.
* Existing active reviewers will be required to meet requirement 1 by January 1, 2008.

Existing inactive reviewers will need to meet both requirements before they are allowed to become active.

To review a C++ component, a member will need to be an active, qualified reviewer in either Java or .NET for the discipline they want to review in (design or development).

As before, TopCoder will occasionally grant an immunity from these requirements to certain otherwise highly qualified designers or developers. For example, a member architect may be granted a design review immunity if they are being prevented from staying active in component design due to their architecture obligations for TopCoder.