Help:Project Names

Search WikiTree's help pages:

Categories: Sysop Help

The following is an early draft of rules and principles on naming Projects, Sub-Projects, and Free-Space Projects.

Freedom vs. Consistency

We want to allow project leaders and members as much freedom as possible in choosing a name.

If members find a certain name for their group inspiring, fun, or whatever else, we don't want to discourage their enthusiasm. Enthusiasm is an important ingredient in successful projects. Moreover, choosing your own name can give the member more of a sense of ownership and pride.

Note that some top-level projects do want to enforce some consistency in the naming of their sub-projects. This is up to them.

Rule of thumb: The amount of freedom roughly parallels the three levels of project formality. Free-space projects can be named more freely than formal projects. Top-level projects may need constraints because they may need to encompass sub-projects and free-space projects.

Top-Level Limits Mean Future Changes in Names and Structure

One of the central reasons we need some consistency in naming is the limit on the number of top-level projects. We never want more than a few hundred top-level projects. Partly this is just because we can't have thousands of project badges.

When we start to get too many top-level projects, some top-level projects may either need to:

  1. adjust their project name and scope, or
  2. become a sub-project.

For example, Irish Roots may be a top-level project right now. At some point we may need to either change it to an Ireland Project or make it a sub-project of Ireland or an ethnic roots top-level project.

If someone wants to create a "roots" project there is no need to force them to create a country project instead, unless we're reaching the limits or there is already a top-level country project. For example, if someone wants to create a "Spanish Roots" project instead of a "Spain Project" that's up to them, unless there already is a Spain Project, in which case their idea should probably be a sub-project.

Rule of thumb: We don't need to enforce much consistency until we start reaching the limits, but Leaders should be aware of the need for future flexibility.

Categorization Relieves Pressure

Our recent efforts to create a good way to browse subcategories of Category:Projects means that some of the need for naming consistency is gone. We don't need naming consistency for the sake of making projects easier to find. The categories can do that.

The project categorization hierarchy needs to be broad and all-encompassing. The project level hierarchy does not.

In some cases, the project categorization hierarchy may perfectly match the project hierarchy. For example:

  • There is a Global Cemeteries Project top-level project and there is a Cemeteries Projects category.
  • Beneath the global project are regional sub-projects. Beneath the Cemeteries Projects category are regional sub-categories.
  • Beneath the sub-projects are free-space projects for individual cemeteries. These correspond to items in the categories.

This perfect alignment is not necessary. For example, we can have a European Projects category without having a European Project as a top-level project with individual countries as sub-projects.

In some case it may be necessary for other reasons to create top-level projects or sub-projects when they wouldn't otherwise exist because we need a placeholder project with a formal Leader. For example, you might have sub-projects and free-space projects for African countries led by Project Coordinators and regular members. We may need to create an Africa top-level project to create the badge.

Rule of thumb: If any individual country project meets the requirements for a top-level project, it can be a top-level project, unless or until we run out of space and need to make some of them sub-projects.
Language: en | de

This page was last modified 14:59, 22 October 2020. This page has been accessed 109 times.