Jay,
RTC has a very complex security model and it's not something that I can explain easily in a forum post.
I suggest you start from reading https://jazz.net/library/article/215
I think it's important to understand the various source control artifacts and how they relate to each other (e.g. change set, component, baseline, snapshot, stream, repository workspace) before you can answer your own question. Here's a quick overview.
Disclaimer - although I'm not an RTC SCM developer, the following is how I usually explain it to my users. You can view my explanation as a narrative, rather than the absolute truth, much like we're used to seeing on the news these days :-).
Source code artifacts (such as streams and components) have two important properties that you need to take into account. These are ownership and visibility. The first one defines who has write access (usually a process area such as a project area or a team area, or an individual contributor). The second one describes who has read access (i.e. can see the code). Visibility can be set to a process area or individual or access group (i.e. a repository wide, rather than project area specific, equivalent of a team area). A project area also has access control rules that govern who can see the artifacts within it. Unless project areas have the "Everyone" access rule, they are designed to provide a layer of isolation between different project teams.
The code is actually stored in changesets that are "contained" in components. The component is really just a "bag" of changesets (each of the latter knows its predecessor). Therefore, the component doesn't really have structure by itself and you can't just look into a component and see the source in it without an additional construct that gives it structure. One such construct is a baseline. It's effectively a view of all of the source within the component at a particular point in time. So if a component has 100 changesets, only 50 of those may participate within a specific baseline. Configuration objects, such as streams and repository workspaces, group component baselines together and keep track of additional change sets on top of them. A snapshot is simply a collection of baselines (i.e. one baseline per component based on the original configuration object that the snapshot was created from).
So the question becomes who owns your stream and components (can write to them) and who has visibility to them. If Project A owns the stream and components, and your project areas are locked down to only members of the project areas, then unless people from Project B and C are also members of Project A or are in an access group that is defined as the one that has visibility to the stream/components, they won't have visibility to the code. One option you have is to create a stream in project B or C that consumes the same components that are used in Project A. This way, Project A can iterate on the contents of Stream A and when they're ready to share their code with Project B and C, they can baseline their components and Project B and C can "rebaseline" their streams to the same level of code as Project A. The other option is to define an access group that contains all of your developers from Projects A, B and C and make the components and stream visible to that access group. Again, remember that the team that owns Stream A will still be the only one that can write to stream A and if that team only contains Project A developers, the other teams will only be able to see the source but not modify it (unless they have their own streams in their project areas that they are responsible to maintain as I outlined in option one). The third option is to create a separate project area for development that will own all of the source and all of the team members from Projects A, B and C will be defined there. Project specific artifacts can still be defined in segregated project areas but developers will always come back to the Dev project area to do any source code management. Lastly, rather than splitting out all of the project areas, you can use team areas within a single project area to provide you with the isolation you want. That is, you can lock it down so that work items that are categorized for a specific filed against category are only visible to the team area that is associated with that category. The approach that's employed by IBM's SAFe implementation uses team areas within a single project area (program) to represents different "projects" although they don't necessary lock down access to team specific artifacts unless you need that level of security within your organization. Unless you need a different process (e.g. different work item types, workflows, roles, permissions) to be used by the different project teams, this is the approach I recommend wihin my organization as well.
#Engineering#Sustainability