moving to correct component

Martin:
You should raise this with the XML project lead, who can create in CVS a module as 
you specified and assign you the role of module owner. It's a little tricky, but I can 
help out (ie, do it), once he's give the say so.
alternatively, you can create a new project. Less desireable, to be sure, and the 
protocols are still being finalized.
louis

Martin:

You should raise this with the XML project lead, who can create in CVS a module as 

you specified and assign you the role of module owner. It's a little tricky, but I can 

help out (ie, do it), once he's give the say so.

alternatively, you can create a new project. Less desireable, to be sure, and the 

protocols are still being finalized.

louis

For me its okay to have a sub module called standardisation within the
xml/www module, as long as the people that have commit access there
don't have commit access to xml/www or some other project
automatically, too.

Martin, if you need some modifications to the xml/www webpage itself
please contact Daniel Vogelheim.

Michael:
Let's move on this, then.
1. create the modules desired in cvs.
2. I can create the resource/roles required, with the full 
limitations
3. you can then grant the members those limited roles, so they 
can have cvs commit privileges only for the specified module.
But first: the module must be created in cvs.
louis

Louis,

Can you tell me how to do that? I'm presuming I can do it, as 
Michael isn't here currently.

Martin

Louis,

I added a new directory to xml/www called standardisation.
Is this sufficient?

Martin

Assigning to Louis.

Martin,
It is. I'll get to it today.
What I'll do now is create a resource, a role and associate the 
two so that those with that role will only be able to have commit 
access to that module. Complicated, but it works.
For future such issues, I think we need to establish a policy: 
larger projects merit their own category, or group.
louis

Martin,

It is. I'll get to it today.

What I'll do now is create a resource, a role and associate the 

two so that those with that role will only be able to have commit 

access to that module. Complicated, but it works.

For future such issues, I think we need to establish a policy: 

larger projects merit their own category, or group.

louis

I created the discuss list office_standards@openoffice.org. You have 
to be subscribed to post.
Moderators: mib, mtg, louis
Owner: st
As soon as I see the list is running I will give ownership to louis.

Okay, I think I did it.
I created a resource/role, Standardisation Module Developer, added Martin G. (mtg) 
to XML (where he was already a member) with the role. He is now a developer in the 
Standardisation module. he may want more privileges (don't we all?), in which case 
the role's privileges can be altered, perhaps to make him an owner of that module. 

For now, others can be added to that module w/ commit privileges by adding the 
reg. user and giving him/her that role.
Regarding mailing lists: the project lead can create them.
and: keep in mind that larger projects merit their own category, for ease of admin.
louis

As agreed with Louis, we can close all the resolved fixed issues he owns.

As agreed with Louis, we can close all the resolved fixed issues he owns.