Hi,

I will try to start answering your questions. You might want to consider getting in contact with a consultant though.

Filters: For instance in the Team Artifacts view there is an actions menu on the top. That allows to do several things such as accepting invitations. One symbol has three arrows pointing to the right similar to:

-->|
----->
-->|


This allows to filter out things. There are default filters and you can try playing with MyFilter. This however requires that the Streams are owned by different teams to be of use. E.g. a Maintenance V1.2 team owns a stream and you are no member of it.

You don't have to keep all streams for your modules, if you don't work on them. You can create snapshots/baselines of the configurations. Streams can easily be created from Snapshots if needed.

How to use Projects is really driven by what your requirements are for instance from an organizational perspective, how much effort for administrating is acceptable and if there is a requirement of isolation. The current recommendation I guess would be to use as few as possible. If there is no requirement to block certain groups of people in your organization from looking into each others artifacts and you all can work on the same base process (work item types etc.) you can stay with only one project.

You can create separate timelines to have different schedules for different activities. You can create complex team area hierarchies e.g. to give all 12 maintenance teams their area to plan work for this quarter which brings us back to the filters. Streams have owners (e.g. team areas). The team area that owns it controls its modification permissions and rules. There are some nice articles in the http://jazz.net/library/.

There are also some nice blogs I'd suggest you to look into.

Thanks,

Ralph

A colleague of mine (Dan) posted a pair of topics that, amongst other things, helped to generate a possible approach for streams in RTC.

Currently we have 12 separate modules (avoiding using the word "components" here), each of which has 1 or more historical release versions. If we were to create a stream for each release version of each module, we would have 45 streams today and add 12 with every release or fix pack.

Is this normal/reasonable/typical? I've only just started experimenting with the fat client*, so it is quite possible that I'm not using the right "view", but it appears all streams appear in a single list without any filtering or hierarchy - with a large and growing number of streams, I have to assume this is or will become a usability issue.

In an earlier topic (http://jazz.net/forums/viewtopic.php?t=13345), the poster was advised that "You can use the 'my teams areas' filter to keep the number of streams in the Team Area Navigator reasonable." Where are these interface elements?

Finally, our assumption so far has been that we will be using a single "Project", but I also do not know if that is recommended - how are Projects expected to be used - for different products? for releases of a product?


Thanks very much for all assistance.


Dan's earlier topics:
http://jazz.net/forums/viewtopic.php?t=13838
http://jazz.net/forums/viewtopic.php?t=13572


*As an side it is truly fat - over 200mb memory use and we don't have much setup yet. Any advice on reducing this, perhaps by disabling unneeded options?

Hi,

I would definitely suggest to use snapshots for the released code. That would be the best way to be able to recreate the code later from the SCM system. Also you might want to be able to compare snapshots (and the created baselines).

If your team is quite small and you have literally only one person in several cases that do all the work, I'd like to suggest a different approach. It does not make sense to define tons of teams with only one person in them.

Lets assume you have all the streams for all your versions. Lets assume you have few teams for instance development, maintenance A maintenance B etc. I'd need to know how you organize your work over time to make suggestions on the team structure if you want to make use of the planning component.

Lets assume for now there is just one team and thus the stream filtering is not so useful.

You could still organize using repository workspaces. If only one person works against a released version, the stream is not that much of interest, because the stream is typically the place several users share changes.

In these cases users would primarily have repository workspaces they own (and that flow against one or more streams). The main place to organize would be the repository workspaces and those are automatically filtered down to the user. So most of the time your users would not really be interested at all in the streams but rather look at their repository workspaces.

There is Jazz Source Control Search, that one can use to search for repository workspaces owned by a single person. From that you can find the stream it flows to.

So basically you could organize around repository workspaces and would not really care for all the streams.

You might be able to split your teams into "Module teams". Not sure.

Ralph

Hmm. Despite the fact that we have 12 modules, our team is not very large, and several modules are the responsibility of single people. This sounds like we'd have to create a bunch of teams of just one person and have some people in multiple such single or two person teams in order to use that kind of filtering. Also, we are the kind of place where push-comes-to-shove, anyone can work on any module, so we'd slowly get to a state where every developer is on every team and have the same issue.

I could be misinterpreting, but so far we haven't considered snapshots because almost every release of every module is still supported and may require maintenance, so we can't freeze them.

One tidbit just came up with Projects - apparently you can run into problems with separate Projects that have streams with the same names. (!)

I will looking into the link and blogs today - thanks very much for your response!

Now you got me thinking.

You might as well look into using work items for tracking the Builds that you release. The Builds can be used to create work items against them. The builds can also have snapshots that are automatically created and can be used to create a repository workspace or a stream from them. You would keep the builds that have been released and use the work items (maybe a special type) to track where the build has been deployed etc.

Work item queries would allow to search for those work items and from the work item you can get to the associated build, the related snapshot etc.

You can mention the build tracking work item if you fix things for the build.

Just some thoughts.

Ralph