Version 4
Created by unibrew on Apr 28, 2008 2:11 PM. Last modified by unibrew on May 7, 2008 4:29 PM.

    JBoss.Org-NG Specification

    Project Sites

    All "project site" prose content must be driven through the wiki as a CMS.

     

    Pages

    1. For a project's site URL www.jboss.org/PROJ each page must provide navigational elements/links to:

      1. The project's entry in the project directory (www.jboss.org/directory/PROJ)

      2. The project's page in JIRA, if available

      3. The project's FishEye URL, if available

      4. The project's anonymous SVN URL if available

      5. The project's documentation page (www.jboss.org/PROJ/docs)

      6. The project's downloads page in the project directory (www.jboss.org/PROJ/downloads)

      7. Link to the join-this-project flow for potential contributors

    2. The front/main/top page should involve a beautiful URL. www.jboss.org/PROJ/content.

    Content pages

    1. Content pages beyond the front/main/top page do not necessarily require beautiful URLs. 

    2. All content pages must be bookmarkable.

    3. Content must only be editable by approved users (see Role discussions below)

    4. Each page must provide a project-maintainable navigational element.

    Style/Theme/Brand

    1. Each project site must present a look-and-feel consistent with JBoss.org.

    2. Each project site must allow customization of at least

      1. Logo

      2. Selection from a finite, pre-selected color palette.

    Provisioning

    1. When a project is accepted through the project-submission workflow...

      1. An initial "main" page for the project is created, content populated with information from the meta-data repository.  This may include

        1. A "comming soon" disclaimer

        2. General information about JBoss projects

        3. General project description as contained in the repository.

      2. The main page should not include

        1. Instructions to the project leads on what to do next.  Most people coming to the page are not project leads, so the page is not an appropriate avenue for communicating only with leads.

      3. The original project submitter must be granted edit access to the pages/space for the new project within the wiki.

    2. When a new user joins the project through the project directory, and the project lead has accepted his application...

      1. The new user must be granted edit access to the content for the project in the wiki.

    3. When a user is removed from a project through the project directory, his edit access must be revoked in the wiki for the content related to that project.

    Global .Org Presence (www.jboss.org/)

    Front page (www.jboss.org/)

    1. The front page of jboss.org must be customizable from a design point-of-view. James may wish to refresh/alter the design on a regular basis to keep things interesting.

    2. The front page of jboss.org must display administrator-selected headlines and abstracts for entries selected from the feed archive. The administrator must also be allowed to determine the order of the headlines displayed.

    3. The front page of jboss.org must display the latest X releases (pulled from the meta-data repository) across the entirety of projects hosted.  Each release displayed should include

      1. Project name, asset name (if different), version

      2. Date/time of the release

      3. Links to source and binary, if both are available

      4. Link to release-notes, if available

    4. The front page of jboss.org must display the latest X headlines of blog entries across project-related blogs. These should pull only from the official project blog sources.

    5. The front page jboss.org must display the latest X podcasts across official blog sources.

    Community Verbiage (jboss.org/community/)

    For pages such as "How to join" or "Governance rules" and other stuff that lives under /community currently, implement Just Like a Project, with the project site backed by the wiki, as usual.

    Events announcements

    For HTML pages containing information about some events. The page should be rendered without any standard theming. It should be served under a nice URL (TBD jboss.org/events/ , events.jboss.org/ )

    Downloads (www.jboss.org/downloads)

    1. Dynamically-generated tabular listing of latest project asset downloads.

    2. For each asset, data must include:

      1. Project name, asset name (if different), version

      2. Date/time of the release

      3. Links to source and binary, if both are available

      4. Link to release-notes, if available

    3. Links to project's own downloads page for "for additional available versions" since only the latest are listed on the global downloads page.

    Feeds (www.jboss.org/feeds)

    1. Primary feeds page (feeds.jboss.org/) must display latest 20 headlines and abstracts from official project feeds.  Page should provide additional links for paginating through historical entries.

    2. Community feeds page (feeds.jboss.org/community) must display latest 20 headlines and abstracts from all community-approved feeds.  Page should provide additional links for paginating through historical entries.

    3. Navigation to project-level feed aggregators must be provided

    4. Any aggregation of feeds must provide an OPML representation of the set of feeds

    Member Directory

    1. Provide a method for browsing registered users alphabetically.

    2. Provide a way to browse geographically

    3. Display users on a map

    4. Filter by project and/or role

    Member Profile Page

    1. Each registered user of jboss.org must have a "profile" page, located at a URL similar to www.jboss.org/members/<some-hash-code-or-id> or www.jboss.org/members/USERNAME.  This needs to be decided, as some users use their email address as their username.  And leaking email addresses would not be cool.

      1. Include the follow user tidbits of information, if provided

        1. Real name (or alias)

        2. Image (120px by 120px square, or such, "avatar")

        3. Location

          1. Publicly display only down to the city level.  No street addresses.

          2. Draw it on a Google map

        4. Blog URL(s)

        5. Other URL(s) (LinkedIn profile, Facebook profile, etc)

      2. From the meta-data repository:

        1. Project memberships, and roles

        2. Links to user's corresponding profile pages in JIRA, Wiki, FishEye

    2. Each user must have a form for editing/updating all of his profile information

      1. For location, accept fully-detailed specific addresses, but ensure they are anonymised before being used publicly

    New Project Submission

    1. Any logged-in user can submit a new project idea.

      1. Each submission must include

        1. Name (ie, "JBoss jBPM")

        2. Desired id/short name (ie, "jbpm")

        3. Description

        4. License (selected from list)

        5. Desired group(s) (ie, SOA, Framework, Runtime, Portal)

        6. ...

      2. Each submission may optionally include

        1. Current code location URL if currently hosted elsewhere

        2. Current doc location URL if currently hosted elsewhere

    2. Each submission enters an approval queue

      1. Upon entry, notification is sent via email to .org Administrators

      2. Queue must be viewable as an authenticated RSS feed

      3. .org Administrators can view the queue, and for each submission

        1. Reject the submission

          1. Rejection requires a "reason"

          2. Rejection sends a polite email with

            1. Boilerplate "don't feel bad" text

            2. The specific reason denoted by the administrator

            3. cc:'s the administrators

        2. Respond to the submission

          1. Sends a response via email to the submitter, typically requesting more information or changes to the submission.

          2. Removes the submission from the queue of awaiting acceptance submissions

          3. The submission is added to holding queue.

          4. Allows the previous submission to be edited and re-submitted

        3. Accept the submission

          1. Optionally edit the submission before accepting

          2. Upon acceptance

            1. provision services, per the submission

              1. Forums or mail-list configuration for the project

                1. The submitter must be granted moderator access

              2. New JIRA project

                1. The submitter must be granted project-lead status

              3. New Subversion project

                1. The submitter must be granted write privs to the repository and the admin/ directory

                2. SVN::Notify or other post-commit hooks configured.

              4. Fisheye

                1. The new project must be configured in FishEye

              5. downloads.jboss.org, repository.jboss.org, snapshots.jboss.org

                1. Create a new directory structure and grant submitter access

              6. docs.jboss.org

                1. Create a new directory structure and grant submitter access

              7. Kosmos/JMM

              8. Project Site in Wiki

                1. See project spec above, under "Provisioning"

              9. Project Directory

                1. begin serving www.jboss.org/directory/PROJ/ pages dynamically

    Project Directory Entry (www.jboss.org/directory/PROJ/)

    Main directory entry page (www.jboss.org/directory/PROJ/)

    Each project must have a main directory page displaying summary/overview information populated from the meta-data repository and other sources, displayed in a standard form.

    1. Latest X headlines from the project'sfeeds

    2. Latest releases links

      1. Latest GA for each asset

      2. Latest Alpha/Beta for each asset

      3. Night snapshot download link, if available

    3. Last 10 bugs opened in JIRA for the project

      1. With link to jira.jboss.org query to view a fuller report of recently-opened bugs

    4. Last 10 bugs resolve in JIRA for the project

      1. With link to jira.jboss.org query to view a fuller report of recently-resolved bugs

    5. Links to

      1. FishEye

      2. JIRA

      3. Anonymous Subversion

      4. Committer Subversion

      5. Kosmos/JMM for the project

      6. Member directory displaying project contributors on a map

    6. Listing of project administrators

      1. Links to their profile pages

    Member Roster (www.jboss.org/directory/PROJ/roster)

    1. Each project must have a synthetic www.jboss.org/directory/PROJ/roster page generated to display the current members of the project, and their role(s). 

      1. Project administrators can add/remove, promote/demote individual roster members

      2. Changes in roles require changes in access in all connected services

        1. add/remove Subversion access

        2. add/remove JIRA access

        3. add/remove Project Site in Wiki access

        4. add/remove Forum moderator privs

    License (www.jboss.org/directory/PROJ/license)

    1. Each project must have a synthetic www.jboss.org/directory/PROJ/license page generated to display the current license of the project.

    Downloads (www.jboss.org/directory/PROJ/downloads)

    1. Each project must have a synthetic www.jboss.org/directory/PROJ/downloads page generated from the list of registered releases.

      1. Should be organized by project asset and version

      2. Each entry should provide links to

        1. Date/time of the release

        2. Links to source and binary, if both are available

        3. Link to release-notes, if available

    Feeds (www.jboss.org/directory/PROJ/feeds/)

    1. Each project must have a www.jboss.org/directory/PROJ/feed page aggregating official project feeds

      1. It must allow pagination through the historical archive

    2. Each project must have a www.jboss.org/directory/PROJ/feed/community page aggregating all approved community feeds related to the project, if any, in addition the the previous official feeds.

      1. It must allow pagination through the historical archive

    3. For community-submitted blogs or pages, project administrators must be provided a queue for accepting or rejecting submissions.

      1. Queue itself must be made visible as an RSS feed

      2. New items must trigger an email to the project administrators

    Documentation (www.jboss.org/PROJ/docs)

    1. Each project must have a www.jboss.org/directory/PROJ/docs page providing links to official project documentation (ie, DocBook).

    2. Each document linked should also provide link to the clearspace annotation/comment page for that document within the project's site.

    Join the Project

    1. A user may apply to join a project from the project's entry in the directory.

      1. With his application, he may optionally include a comment/note.

      2. With his application, he may select one-or-more roles he's hoping to attain

        1. Committer to code repository

        2. Editor of site content in wiki

        3. Translator of documentation

        4. ...more to be specified as needed

      3. If the user has no Contributor Agreement on file that is compatible with the project's, he must be prompted to sign a contributor agreement.

        1. If the contributor refuses, the application must be automatically rejected

        2. If the contributor agrees, the application must continue to be processed.

    2. All user applications for contribution enter a queue for project-lead approval. 

      1. All applications in the queue must represent users who have already signed a compatible Contributor Agreement.

      2. Each new application in the queue should generate a notification to the project administrators for a project.

        1. Email to the administrator

      3. Queue should be visible as an RSS feed with authentication

    3. An application, when rejected

      1. Can accept an optional reason from the project administrator

      2. Sends a polite email to the applicant with boilerplate text and the optional reason

        1. cc:'d to the administrators of the project

    4. An application, when accepted

      1. Gives the administrator a chance to adjust roles before confirming

      2. Sends a polite email to the applicant with

        1. boilerplate text about contributing to JBoss projects in general

        2. helpful information for the specific project (Committer URLs, JIRA, etc)

      3. Provisions the user's permissions in various systems based upon the roles

        1. Administrator

          1. Grants access to perform releases (downloads.jboss.org/repository.jboss.org)

          2. Plus everything of Committer

        2. Committer

          1. Grants "Committer" role in JIRA, if not already held

          2. Grants read/write to committer Subversion repository

          3. Plus everything of Editor

        3. Editor

          1. Grants write access to the project's content in the wiki

        4. Translator

          1. See Mark Newton

    Integration with Project Workflow

    Integration to collect meta-data is required.

    1. Releases

      1. .org must provide a standard maven plugin to inject release information into the meta-data repository during normal maven-based releases. 

        1. Upon creation of a Release meta-data object, the administrators should receive an email with a link to edit the release information.  They can provide additional information, URL for release notes (if not provided), etc.

      2. Updating the meta-data repository must automatically update the global and project-level downloads pages

    2. Snapshots

      1. When nightly or snapshot builds are created, .org must integrate a trigger into the maven snapshot process or the CI build notifier.

     

    5449 Views Categories: Tags: