The .NET platform currently has a active open-source development community. This community has produced several products meant to run on the .NET platform. Since the .NET platform is assembly based, most of these products are comprised of several, smaller sets of useful utility classes. Many of these classes are meant to augment the original .NET framework, providing what is percieved to be missing core functionality. Since many of these the larger projects will be integrated with each other on any given project, it makes sense to collect these smaller sets of utility classes into one common project.
Scope of the subproject
The subproject shall create and maintain an assembly, written for the .NET platform, intended for use in development, and designed to be used independently of any larger product or framework. The assembly will be managed in the same manner as a larger Jakarta product. To further this goal, the subproject shall also host a workplace for Jakarta committers.
Identify the initial set of committers
- is, has, will, shall, must - required.
- may, should, are encouraged - optional but recommended.
- The primary unit of reuse and release is the assembly.
- The project is not a framework but a collection of classes, designed to be used independently.
- Each namespace must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts.
- Each subproject must clearly specify any external dependencies and the earliest .NET runtime version required.
- External dependencies on optional and third-party codebases should be minimized.
- The subproject should use a standard scheme for versioning, unit tests, and directory layouts, and a common format for documentation and NAnt build files.
- The subproject should fit within a unified namespace hierarchy.
- External configuration files are discouraged, but if required, .Net XML format files are preferred for configuration options.
- The project will also host a top-level 'general' mailing list.
- The subproject will also provide debug & release builds for releases, including debugging symbols. A dump of nightly builds will also be provided, but will only be a debug build.
- Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite.
- Each committer has karma to all the subproject.
- New top-level namespaces may be proposed to the Jakarta .Net Commons mailing list. Examples of a top-level namespace include NetCommons.Collections and NetCommons.Threading. To be accepted, a namespace proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the namespace, its scope, its interaction with other namespace and products, the .Net Commons classes, if any, to be created, the initial source from which the namespaceis to be created, the coding conventions used for the namespace and the initial set of committers.
- As stated in the Jakarta guidelines, an action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes.
- Anyone may propose a new top-level namespace to the .Net Commons, and list themselves as the initial committers for the package. The vote on the proposal is then also a vote to enter new committers to the subproject as needed.
- A CVS repository will be available to all Apache committers as a workplace for new sub projects or other projects.
- Each .Net Commons namespace should use an internally consistent and documented coding style. When the source code for a component originates in a pre-existing code base outside of .Net Commons, the coding style of that code base may be retained at the discretion of the initial committers. If a component does not specify its coding style, the Microsoft Coding Convention guidelines are assumed.
- The subproject catalog will also list assemblies and resources available to the public related to other Jakarta subprojects and ASF projects.
- As a Jakarta subproject, the .Net Commons adopts all other guidelines and procedures of Jakarta and the Apache Software Foundation, as they may be amended from time to time.
- All public members of any .Net Commons subproject API written in the C# language shall utilize Microsoft's XML comments.
Example Project Proposal
Proposal for Collections Namespace
Many .Net OSS software projects utilize classes that were donated by the author of the Iesi.Collections project and documented in an article on Code Project. Other collection implemenations have since been created, in addition to the original classes found within Iesi.Collections. These are useful collection classes that are missing from the .Net FCL. Examples include Sets, LinkedLists, and Queues.
There are several implementations of these classes already available. A .Net Commons namespace would give committers an opportunity to coordinate their efforts to create and maintain a efficient, feature-rich package under the ASF license.
Scope of the namespace
The namespace shall create and maintain collections written in the C# language to be distributed under the ASF license. The namespace shall be available as interfaces, as well as default implementations to those interfaces.
Identify the initial source for the namespace
The initial spirit of the codebase was introduced by Jason Smith, in a Code Project article. Collection class implementations from several OSS projects will be used as the initial codebase.
Identify the base name for the namespace
Identify the coding conventions for this namespace
The code uses the conventions from the Microsoft Design Guidelines for Class Library Developers guide.
Identify any Jakarta-NetCommons resources to be created
Until traffic justifies, the namespace will use the Jakarta-NetCommons list for communications.
For the time being, the namespace will use a root branch of the Jakarta-NetCommons CVS.
The namespace should be listed as a component of under the Jakarta-NetCommons Bugzilla entry.
Identify the initial set of committers to be listed in the Status File.