I'm playing with this new feature... I was able to create a master project area (had to remove the timelines config first), and then I created another project area and specified to use the process of the master, as defined on the beta 2 scenarios:

https://jazz.net/wiki/bin/view/Main/RTCBeta2EnterpriseProcess

I cannot understand the difference. Is it working as expected? I created a new WI type in the master, but nothing happens in the 2nd PA...

Ideas? Any material that I can review to understand it better? Thanks,
--Claudia Callegari

Hi Claudia,

What's the process template are you using?
1.For the master project area, you can use Scrum template to avoid the deletion of the configuration of timelines and iterations.
2.For the project area that consumes process provider, you should use th e "Unconfigured Process Template".

Also, you can set the process in the master project as "final", which
then causes the process definition in the slave projects to be ignored.

Cheers,
Geoff

On 11/8/2010 9:23 PM, ThomasYu wrote:

ccallegwrote:
I'm playing with this new feature... I was able to create a master
project area (had to remove the timelines config first), and then I
created another project area and specified to use the process of the
master, as defined on the beta 2 scenarios:

https://jazz.net/wiki/bin/view/Main/RTCBeta2EnterpriseProcess

I cannot understand the difference. Is it working as expected? I
created a new WI type in the master, but nothing happens in the 2nd
PA...

Ideas? Any material that I can review to understand it better?
Thanks,
--Claudia Callegari

Hi Claudia,

What's the process template are you using?
1.For the master project area, you can use Scrum template to avoid the
deletion of the configuration of timelines and iterations.
2.For the project area that consumes process provider, you should use
th e "Unconfigured Process Template".

BTW, having to use the "Unconfigured Process Template" in order to share
process appears to make it infeasible to "adopt" a master project for an
existing project, which in turns makes it infeasible to put any existing
upgraded 2.0 projects under control of a master project. This would be
very unfortunate ... could someone from the process team comment on
this? (I'll also submit a work item on this when the jazz.net server is
back up).

Cheers,
Geoff

On 11/9/2010 12:34 AM, Geoffrey Clemm wrote:

Also, you can set the process in the master project as "final", which
then causes the process definition in the slave projects to be ignored.

Cheers,
Geoff

On 11/8/2010 9:23 PM, ThomasYu wrote:
ccallegwrote:
I'm playing with this new feature... I was able to create a master
project area (had to remove the timelines config first), and then I
created another project area and specified to use the process of the
master, as defined on the beta 2 scenarios:

https://jazz.net/wiki/bin/view/Main/RTCBeta2EnterpriseProcess

I cannot understand the difference. Is it working as expected? I
created a new WI type in the master, but nothing happens in the 2nd
PA...

Ideas? Any material that I can review to understand it better?
Thanks,
--Claudia Callegari

Hi Claudia,

What's the process template are you using?
1.For the master project area, you can use Scrum template to avoid the
deletion of the configuration of timelines and iterations.
2.For the project area that consumes process provider, you should use
th e "Unconfigured Process Template".

On 11/9/10 12:53 PM, ccalleg wrote:

What do you mean by "Unconfigured Process Template"? When
creating a new PA I can only see the following processes:
- Cloudburst
- Formal PM
- OpenUp
- Scrum
- Simple Team
So no "Unconfigured Proc template"...

I also tried checking "I will review the process specification
before I manually initialize the project area", so I created the
PA, specified to use the master project, and manually intialize, but
do not understand the behavior.

Thanks in advance for your guidance and advise.
--Claudia

You may have to redeploy the process templates in order to see the
'Unconfigured Process Template'.

--
Regards,
Patrick
RTC Work Item Component Lead

What do you mean by "Unconfigured Process Template"? When creating a new PA I can only see the following processes:
- Cloudburst
- Formal PM
- OpenUp
- Scrum
- Simple Team
So no "Unconfigured Proc template"...

I also tried checking "I will review the process specification before I manually initialize the project area", so I created the PA, specified to use the master project, and manually intialize, but do not understand the behavior.

Thanks in advance for your guidance and advise.
--Claudia

If you didn't see the "Unconfigured Proc template",you can create a simple process template using the Process Template creation wizard, input the id,summary.And then create a PA based on this process template,then set the master project area to it.

Hi Claudia,

An shared process addresses the need for a common, easily changed process that can be rolled out across an organization. It defines common operation behavior, permissions, and configuration data used in projects. This makes it easier to enforce a common process and to change that process without having to change every project area.

Sharing process is one of the ways we are supporting large installations with many projects. It lowers the cost of adopting process changes because process changes need to be applied to only one project instead of many. It also makes day to day administration of projects easier, since projects may vary only in areas known to the administrators who manage the shared process.

Perhaps I can address some of the other issues that have been raised in this thread.

The Unconfigured Process template was not included in RTC Beta 2, so that may be the reason you are not seeing it. It was included in RTC RC1 and will be available in future betas and the GA. As Thomas mentioned, the process template you created is functionally equivalent to the Unconfigured Process.

The Unconfigured Process is simply an empty process. It does not configure any operation behavior, configuration data, or roles. By using it to create a project area that will consume process, you are ensuring that your project area will not inadvertently override the process you are consuming.

To answer Geoff's concern, existing project areas that were created with other process templates may already define operation behaviors or configuration that will override the process they are consuming. In this case, administrators may choose to mark parts of the process provider as "final", or they may remove the existing configuration from the existing project area. The removal can be done by editing the XML source in the Eclipse client. The process team has thoughts on how to make this easier, but support for automating the removal did not make it into the 3.0 release.

I hope I have answered your question about the business reason and any remaining doubt about how the feature works. If not, please reply here; I will be following the conversation.

Martha
Jazz Developer, Process Team

As I was not able to see the Unconfigured proc.template even after redeploying the templates, I created an unconf. proc. template from scratch using the wizard.

Now I can see that even if my slave PA is unconfigured, it "inherits" the process definition of the master.

Can someone explain the business reason for this feature, so I do not missunderstand the real purpose envisioned by Rational team? Thanks

--Claudia

Hi Martha (and Everyone),

I am in a similar situation wherein we upgraded from RTC 2.0 to 3.0, and would like to take advantage of the process sharing functionality. I followed Claudia's steps and created an Unconfigured process template, and managed to get the process sharing working.

However, I do not understand how to go about overriding the shared process template selectively. For example, one of the projects wants a minor override to the shared process template's permissions, so that they can make changes to a custom attribute. What is the best way to make this change?

If I go through the "Process Configuration" tab and edit permissions for modifying that particular attribute, the other permissions are lost because this one change is causing an override of ALL permissions inherited from the shared project's process. In other words, the XML source is now defining permissions very narrowly in the <role> and <operation> hierarchy.

So what is the right "granularity" for editing the XML? Do I need to copy the XML source under <permissions> from the shared process, and then edit it? Or does this need to happen at the <team> level? What will happen to stuff defined under <project> if the "child project" modifies the <team> section? Will it still be inherited from the shared parent?

I hope I have explained my problem clearly. Please let me know if you need any clarifications.

Thanks.

Hi Martha (and Everyone),

I am in a similar situation wherein we upgraded from RTC 2.0 to 3.0, and would like to take advantage of the process sharing functionality. I followed Claudia's steps and created an Unconfigured process template, and managed to get the process sharing working.

However, I do not understand how to go about overriding the shared process template selectively. For example, one of the projects wants a minor override to the shared process template's permissions, so that they can make changes to a custom attribute. What is the best way to make this change?

If I go through the "Process Configuration" tab and edit permissions for modifying that particular attribute, the other permissions are lost because this one change is causing an override of ALL permissions inherited from the shared project's process. In other words, the XML source is now defining permissions very narrowly in the <role> and <operation> hierarchy.

So what is the right "granularity" for editing the XML? Do I need to copy the XML source under <permissions> from the shared process, and then edit it? Or does this need to happen at the <team> level? What will happen to stuff defined under <project> if the "child project" modifies the <team> section? Will it still be inherited from the shared parent?

I hope I have explained my problem clearly. Please let me know if you need any clarifications.

Thanks.

The project-configuration and team-configuration sections are totally independent, so you don't ever have to worry about one of those sections inheriting from the other.

As for the granularity question, when you customize permissions you must do so at the operation level. So if you want to make a customization of your parent project area's permissions you should copy the entire operation and make changes so that your customization completely captures whatever permissions you want for that operation (for whatever role you're editing).

Hope that helps.