The "Plone Products Area":/products is a centralized database of useful add-on products for
Plone. Authors of products are encouraged to list their products here.


This is not intended as a replacement for developer-centric systems like
SourceForge or private CVS/SVN repositories — "Plone Software Center":/products/plonesoftwarecenter (the software used to power the Products area) doesn't
require any changes in how you manage your software products. It's primary goal
is to make it easy for the community to understand what products are available,
for integrators to find products, and for evaluators to understand the depth and
breadth of our offerings.

In return for your listing your project here, we'll be able to drive users to
your project, get new-release information listed on plone.org, and (if you put your release files here), take some of the burden of your server for people downloading files. This will make it easier to for you to list your project in places like Freshmeat and Python-specific repositories.

When you add your project to the Products area, you'll have the option of
keeping the following information in it:

* information on particular releases (version 1.1, 1.2, etc.)

* files associated with those releases

* a documentation center (powered by PloneHelpCenter). This grants you the
following categoration options:

* FAQs

* HOWTOs

* Tutorials

* Glossaries

* Movies

* Reference Manuals

* Error References

Of course, most projects won't need all these documentation types, but they
are individually selectable, and you can add new types as needed.

* Improvement Proposal documents ("Plone PLIPs":/products/plone/roadmap and "Python PEPs":http://www.python.org/peps/ are good
examples of this) that will give you automatic roadmap generation like the "Plone Roadmap":/roadmap.

* an issue tracker, powered by "Poi":/products/poi - see "Poi's own tracker":/products/poi/issues as an example.

In the future, we're likely to add:

* Mailing list / forum integration

* Version control integration/browsing

You don't have to use all of these things — if you have your own documentation
section, or prefer to keep docs in your product, you can still use PSC. Even if
you want to actually have the releases on your site, that's fine, too — just
getting the top-level project description into our system will help
immeasurably with our primary use cases of people needing to understand what
products are available.

We understand that many of us prefer to keep our canonical information on other
sites — Zope.org, SourceForge, a company site, etc. That's fine — we have fields
for giving the canonical location of the project, while still being able to
provide enough description and categorization to be useful.

If you're a software author and considering **not** listing your project here,
or would prefer that your project **not** be listed here, please take a moment
and let us know why (mail the "Plone Website list":/contact#website). We want to make sure that we
build something that is helpful and lightweight enough to be attractive to
everyone, and think there are huge wins if we can all use it. Your feedback
about what doesn't work about this is very very important.

"Plone Software Center":/products/plonesoftwarecenter is the effort of many people (some of whom contributed when
it was called ArchPackage). In alphabetical order: Alexander Limi, Christian
'Tiran' Heimes, Daniel Nouri, Dorneles 'deo' Treméa, Joel Burton, Martin
'optilude' Aspeli and Sidnei 'dreamcatcher' da Silva. Thanks to all of them.

To add a project to Plone Software Center, go to the "Plone Products area":/products and add a "Software Project". You need to provide the following information:

- description

- categories

- proposal types: when you add an improvement proposal (covered later), you can categorize them from this list

- homepage

- repository: a URL for your repository (either a direct URL, like with svn), or a web page that has information on your repository

- tracker: a URL for your bug tracking mailing list or database. In the future, you will be able to add a collector inside your project if you don't prefer to host your own

- mailing list: a URL for information or archives of a mailing list for your project. In the future, you will be able to add a mailing list (perhaps PloneMailBoxer or Mailman) inside your project if you don't prefer to host your own

- logo of your company or product

- screenshot of your product

Once you've added your project, you can then add your releases and actual downloadable files.

From your software project, you can add all the types from Plone Help Center. These include:

- FAQs: Frequently asked questions about your product

- HowTos: explanations of concepts and procedures

- Tutorials: longer, step-by-step explanations (like this one)

- Error Messages: Explanations of common error messages

- Glossary: Glossary of terms

- Videos: Video clips explaining your application

- Reference Documentation

Of course, not all projects will need all of these types — smaller projects may just benefit from a FAQ section and a HowTo section. You can add these at any time, so this grow with your project.

You can add current, old, and new releases to your project.

Releases can hold downloadable files, and can be tied to improvement proposal documents.

Future releases will be listed with improvement proposals that will be included in that release. Current and old releases are listed with their downloadable files.

To add a release, go into the Releases folder in your project, and add a release.

For your release, you'll be asked for:

- version number; PSC will select the next version number for you; you can always change this. Please note that you should not add things like 'alpha' or 'beta' into the version number. Instead, put "2.1" even if it is currently in beta state. This will be managed with the 'state' drop-down menu.

- codename

- description

- release notes

- change log

- name of the release manager

- anticipated release date

- license

- screenshot

Most of these things are optional, and may not be needed for smaller, simpler projects.

You can add improvement proposals to your "Roadmap" folder. Most of the fields here aren't required, and the very-broken-down entry system may not be appropriate for simpler projects or proposals.

IPs are autonumbered, and list by which release lists the IP in its "related proposals" field.

There is a simple workflow for improvement proposals to manage where the IP is in its process.

You can assign local roles in the releases and proposal folders, if you want people to be able to submit proposals but not assign them to releases without your approval. This is also the reason you associate Improvement Proposals to a release from inside the release, and not the other way around.

Part of the goal of Plone Software Center is to make Plone's add-ons more friendly for integrators and end users. For these users, a good name for your product will be very helpful.

I'd recommend you steer away from names that:

- contain implementation-level details

- are excessively technical

- are vague

For example, Plone Software Center itself was originally called "ArchPackage", which violated all three principles:

- it contained the name "Arch", suggesting that it was Archetypes-based. This is not so critical or important feature for someone shopping for a useful software-listing-product that it's worth putting in the title.

- The abbreviation for "Arch" as Archetypes is obscure enough that even some people that know what Archetypes is wouldn't have recognized it anyway.

- The name "package" is too vague for people to understand that these are software products being managed.

With these ideas in mind, I'd steer clear of any of the "CMF*", "Plone*", "AT*" naming schemes. Better is to find a name that users can associate with your product, rather than one that tries to explain exactly what it does, or how it does it.

Good names:

- Haystack (a product for extracting searchable information from data)

- Archetypes

- LinguaPlone

They're all suggestive and "product-y".

Similarly, when writing your project description, consider that people looking at your project may have no idea what is does. Focus on explaining what it is for *rather than* how it works (avoid the tendency to lead with "I used a BTree...", for example).

To help make sure the product repository is as helpful as possible for our community, the plone.org team may suggest edits your project description for clarity.

As of version 1.0, the release mangement process of PloneSoftwareCenter has changed slightly from previous iterations. Please follow these guidelines:

Add releases numbered as they will be in the final release. When you begin work on what will become MyGreatProduct 1.1, create a release numbered 1.1. The title of the release will initially be "MyGreatProduct 1.1 (Pre-release)". This release will start in the "pre-release" state.

When you are ready to make an alpha, beta, release candidate or final release, use the 'state' drop-down to make such a release. The title of the release will change, e.g. to "MyGreatProduct 1.1 (Alpha release)". Note that the state is not applied to final releases (i.e. you do not see "MyGreatProduct 1.1. (Final release)").

If you release a second alpha/beta/release candidate, select 're-release' from the 'state' drop-down. This will automatically increment and add a release number. The title will change to "MyGreatProduct 1.1 (Alpha release 2)". Again, the number is dropped for the first alpha/beta/release candidate, and only shown starting from 2. If you re-release again, the number will be incremented so that you get "MyGreatProduct 1.1 (Alpha release 3)". If the numbering gets out of sync, you can go to the 'edit' tab and edit it. Clearing the field will turn automatic numbering off.

To make a different kind of release, e.g. a beta to follow your alpha, select 'release beta' from the 'state' drop-down. The release number counter will be reset to 1 (and the number hidden for the first beta).

The normal procedure when updating a release between maturities is to delete the redundant files. For instance, when changing an alpha to a beta you would get rid of the alpha release files. This is of course up to you, but we recommend it to minimize confusion on what to download.