patlwrote:
I am a developer at a company planning a RTC roll-out. I have spent
some time reading the documentation on my own, and I have a question
about "team areas" and "project areas".

First, here is what I understand so far; please correct me if I am
wrong. Team areas and project areas form a collection of hierarchies
(trees). Every team area has a parent that is either another team
area or a project area. Project areas have no parent. That is, each
hierarchy has a project area at its root, and each project area forms
the root of a hierarchy of team areas.

My question is this: In an operational sense, what can I do with a
project area that I cannot do with a team area, and vice-versa? Put
another way: Purely in terms of functionality, why would I want to
create two project areas instead of two team areas, or vice-versa?

Do project areas provide some sort of isolation (e.g. access
control) that team areas do not? Can project areas contain some sort
of object (e.g. schedules) that team areas cannot? Are any objects
more easily shared between sibling team areas than between project
areas?

It is possible that my questions are not even well-formed because I
am misusing the terms. If so, please help me to correct that, too.

Thanks!

Your basic understanding is spot on, no need to correct. And thank you
for choosing RTC.

Only Project Areas can have Timelines. A top-level Team Area can be
assigned to a time line (all subteams of it are automatically and
only on that same time line). This makes it possible for a Project
Area to essentially have multiple "projects" if you define
"project" as a Team working within a Timeline to accomplish
something. For example, if you have separate teams responsible for new
development and sustaining work, you could have a Timeline for new
development and one for maintenance. They could have different
iteration configurations and even different process and operational
behaviors defined. Perhaps your new dev Timeline uses short
iterations and your maintenance Timeline uses longer dev-test-release
milestones and all source code deliveries to the maintenance stream
require a code review approval.

While sharing between Project Areas can be done, everything within a
Project Area is implicitly shared -- you actually have to do things
to keep sharing from happening. So one reason you might use 2 Project
Areas is if you want to only share some specific artifacts as it would
be easier to enable that sharing between Project Areas than to disable
all other sharing within one. In the example above, because the new
dev and sustaining teams will likely share lots of information (and
push defects back and forth), a single Project Area is likely a
better choice.

There are specific options for access control at the Project Area
level that don't exist in the same way for Teams. That said, access
control and permissions can be a pretty twisted topic, so if you have
some specific questions, let's look at those rather than discuss it
generally.

You might be interested in this article: https://jazz.net/library/article/137. (Maybe you have already read this article.:)) This article will give you a basic concept about Project Area, Team Area and Process.

The link appears to be broken. @huangqf do you have the right link?

You might be interested in this article: https://jazz.net/library/article/137. (Maybe you have already read this article.:)) This article will give you a basic concept about Project Area, Team Area and Process.