Object Architecture

Please see the DataSchema for more detail about actual data structures.

Nodes

User and Space objects, and perhaps other objects, will be descended from a single virtual base type, Node, probably implemented as a module. This object supports common operations like permissioning, tagging, search, and discussion threads (notes). Every Node has a more particular user or workspace type.

This should have methods like get_permission(userID), get_text, get_YAML_attributes, etc.

Spaces

A Space can represent groups, projects, or software assets. It is a general-purpose container.

We will eventually make many types of Spaces. Developers can extend the Space object.

• Community
• Project
• Software
• Portfolio
  • Repository

A Community is a workspace set up to define a team, assign permissions to the team, and engage in communication or access subsidiary portfolios that "Trust" the Community.

A Project is the default workspace for representing an idea, research in progress, or an active project.

Software represents a software asset (or perhaps some other type of asset) that can be indexed, searched, evaluated, and shared in appropriate workspaces.

A Portfolio is a workspace for containing a list of projects assets to be reviewed and managed by a particular manager, department, or PMO. It has additional data for structuring the phases and planning deliverables.

A Repository is a Portfolio that contains Software assets for sharing with its own team or related Workspaces.

The concept of different Workspace types implies different user interfaces. For instance, the summary screen of a Software node would present a description of the asset and its licensing, but a Portfolio node would present lists. I imagine that the Workspaced concept can be extended to a lot of functionality that involves a team and its relationship to other teams and assets. For instance, you could build a Marketplace workspace that provides eLance/Rentacoder type features for interacting with a selected group of suppliers.

Related Nodes

The most important things about workspaces are their teams and their relationships to other workspaces. We need at least some core relationship types:

TRUSTS: When workspace A TRUSTS workspace B, it accepts the team from workspace B as part of its own team. This is not a reciprocal relationship. If you want the teams to be the same, you need to TRUST both ways. This does not chain, so object A trusts B, but not everybody that B trusts. A Node always trusts itself.

BREAKOUT: When a space is a BREAKOUT of an original space, it is a new space with a new owner, and possibly a private team, to work on the original topic.

RELATED: Topic relationship

LISTENS (Version 2): When workspace A LISTENS to workspace B, it accepts questions and other communications from B, for presentation to its members.

CONTAINS (Version 3, IT portfolio specific): A portfolio or a repository CONTAINS its elements.

CANDIDATE (Version 3, IT portfolio specific): A node may post itself as a CANDIDATE before it gets to CONTAINS status.

USES (Version 3, IT only): If project A is an implementation of Software B, or a customization, or uses Software B as a component, then A USES B. This relationship allows B to send A updates, and it the managers of B to be informed about who they are supporting.

Users

Users have account information and contact information. Permissioning is applied to this information. Each user controls what information should be visible, and to what workspaces. Users can be invited (in which case they get a team membership on registration), or they can register online without a team invitation, access public data, and apply for team memberships.

Should users be a special case of People? Should there be a subset of users called ServiceProviders that can advertise with more information?

User Roles

Teams and Topic relationships are created with UserRoles, a relationship between users and workspaces. Users can gain permissions by being invited as team members with various roles, including "Owner". Users can attach INTERESTED/HAVE/EXPERT relationships to any visible space. Team members can receive alerts from their projects.

The UserRoles? table has provisions for managing users while they are in the state of having been invited, or applying for team membership.

Flow

Discussion threads, composed of notes, can be attached to any node. Also includes issues and questions and any other kind of Flow event. The event types should be extensible. We can filter the view by the type.

I want to include issue tracking fields (priority and status) in the Notes object. I like the workflow where you can take any discussion and put it on an issue list.

Files

Holds documents. Meta tagging for release files? Versioning?

External Links

Assembla is essentially a catalog of past, present, and future resources, along with the commentary and management that is applied to those resources. This might get to be a big catalog, so we need to keep our catalog entries simple. The thing that will make Assembla scalable is its links to outside resources. There at least two kind of links

Search links

A search link specifies external Web pages that should be crawled indexed by the text indexer. Search links are added to Software nodes that describe open source projects or vendor products.

Any link referenced on the Wiki page of a Space will become a search link.

RSS links

An RSS link specifies a feed that should be included in the Flow for a Space

Research Links (Version 2)

Research links are objects that we are assembling in a workspace as a list of candidates. They are similar to del.icio.us bookmarks. They can be Assembla workspaces, or Web links, or pictures, or just text. URL’s can be promoted to Software objects for tagging and commentary.

Portfolios (Version 2 IT only)

A portfolio is a special kind of workspace that helps a manager create a standardized view of a list of workspaces or software assets. Any node in the portfolio has standard planning deliverables - stage and status fields, domain memberships, default tools and worksheets. The manager has a console for configuring these elements of the portfolio. A node can only belong to one portfolio, and the portfolio is selected when the resource is created.

We will add reporting and approval workflow.

Does it require new tables?

Tool links (Version 2)

Tools can be attached to Spaces in order to provide extended capabilities. For example, a Subversion archive, a Trac project workspace, a Wiki, a Plone portal, a cost/benefit worksheet, or a synchronous collaboration channel should all be attachable as resources. Tools will be represented in the system by database entries and by objects that implement interfaces to the tool.

Tools should be integrated with Assembla using a set of scripts which is installed on the tool server that communicate via outward communication to the Assembla servers. This allows external administrators to live behind firewalls and control their interfaces with Assembla. A good implementation of this is to provide LDAP services to outside applications.

Tool links will make it possible to attach tools to an Assembla worksapce. Ideally, we want the following capabilities:

• Permissions to use the tool can be controlled by or synchronized with workspace team membership
• Workspace owners can instantiate standard tools to serve a resource
• Tools feed alert information to Assembla for distribution to team members and RSS subscribers.
• Tools appear on the workspace menu with summary information