This is a summary of SourceForge (SF) features and how they are administered.
These are my (Brent's) notes and may not be 100% accurate.
Pleaes let me know where I'm wrong about something.
The person that creates a project is the default administrator for
that project. They add group members and can grant administrator
rights to other members, as well as admin rights over particular
SF features as described below.
Every project member has CVS write access. By creating
a commitinfo script in the appropriate place, you can further subdivide access
Every project member is part of a UNIX group used for access control to
the various file systems owned by the project. In particular, this includes
/home/groups/groupname/htdocs that is the web site visible as
/home/groups/ftp/pub/groupname that is the FTP site visible as
The admin can set the name, public description, and a
search engine (Trove) categorization.
Additionally, the admin can enable the following features, and each feature
has feature has an "admin" and "tech" role, so someone can be the
"admin" of the bug database without being the admin of the whole project.
Bug Tracker - the bug database.
It has two roles "Tech", which I believe means you can be assigned
bugs and then futz with those bug records, and "Admin", which means
you can futz with any record as well as define the two programmable
fields in the database. There are also batch SQL updates to the
bug database that the bug admin can do. The bug database has
a relatively simple schema:
Status: Open Closed
Resolution: Fixed, Invalid, Wont Fix, Later, Remind, Works for Me, Duplicate
Priority: 1 to 10
Category: programmable, e.g., identifies some area of the software
Group: programmable, e.g., Bug or RFE, or perhaps Version,
Support - a database of support requests.
This is like the bug database, but for support requests. It appears to
like the Bug DB, so the bit about Admin and Tech roles apply.
Patches - another variation on the bug database to collect patches.
It has a programmable "Patch Category" that the patch administrator
can set. Patches can be assigned to project members that have the
"Tech" role in the patch feature. Patches have an
Status: Open, Closed, Deleted, Postponed, Rejected, Accepted, Out-of-date
Category: (programmable by patch admin)
I believe a project can have any number of mailing lists, within reason.
These lists are open to anyone, not just
project members. I think there is a separate list administrator, but
I'm not sure because I'm not using this feature. At any rate, either the
project admin or the list admin requests new lists and maintains them.
Tasks - these are subprojects.
You can create
these and decide if they are visible to non-project members. The Task admin can
create these, and presumably the assigned "Tech" folks can update the task
records. I don't know much more. I think this may be the same
as the "Jobs" that are referenced from the project pages.
web-based documentation - add new docs, view the docs.
Anyone, not even a project member, can submit a doc.
The "Editor" reviews the doc and decides if it should become public.
It isn't clear to me how useful this is in comparison to the
project web site.
I don't see roles split out for this, so probably
only the project admin can create surveys.
post news bullitens.
Any project member can post a message, but the
project admin has to approve it.
These are releases.
The project admin can create releases that appear
on the "Files" section of the SF project. I believe there is a distinction
between these release files and the general FTP area owned by a project.
Any project member can write the the FTP area, but
only the admins can create releases.
The admin can upload screenshots of the application.
Members can keep a diary, public or private.