One of the things we're really struggling with is how the following concepts work together:
1. Project/team hierarchy
2. Permission inheritance
3. Artifact visibility - this includes team dashboards, team queries, streams, & components
4. Stream/component ownership

Currently we have a team organization structured like this in our RTC 3.0.1 repository:
Project P
--- Team A
--- Team B
--- Team C
etc
We are currently adding users to both the project area and their specific teams.

Each team is for a given release so we also have integration and release streams created for each release and owned by the corresponding team.

We want to be able to get the project/team hierarchy and stream/component ownership all correct in such a way that we can:
- we can restrict delivery to streams. We want developers to be able to deliver to integration but not release streams. However, they can have read-only access to those release streams.
- we can also make managing members of areas easier, if possible. We have some base permissions we want all project team members to have (but not necessarily the same as the Everyone default role since that would be everyone on the repository, correct?) but also assign more permissions to that user in child team areas. So you may have base permissions as a member of Project P but have a greater role which adds a wider set of permissions on Team A.

The problem I have is that this is all impacted by how we structure our project/teams and assign ownership and it seems that some of this conflicts when it comes to choosing the implementation.

I feel like I need some further guidance here. Is there any resources that someone more experienced would recommend for understanding some of this?

I guess the net is that I want to better understand:
1. How does the project/team hierarchy and inheritance impact visibility of team dashboards/queries?
2. How is the default everyone role impacted by permissions assigned to it in a project area when also using access control to limit access to members of the project area hierarchy? For example, if in Project P the default everyone role can create a work item, what is the difference for someone listed as a member of the project with no role vs someone who is not a member of the project?
3. What are the different options for restricting delivery (i.e. write access) to specific streams while still allowing read access to it? Are these the same or different for components?
4. What about options for restricting visibility of streams or components to some users?

I think getting help in the form of guidance here in the forum or links to helpful articles will go a long way in helping us determine the right model to follow here.