On Mon, Jul 20, 2009 at 10:18 AM, Alan Burlison<[email protected]> wrote: > Peter Tribble wrote: > >>> The changes between the current and the new version are relatively >>> minor, mainly renaming of roles to reflect the old Constitution. The >>> details of the new version are in the migration documents. >> >> Just minor changes like renaming, or reassignment of rights as well, as >> detailed in the documentation? > > What is described in the documentation is a mapping, rather than a > reassignment. As I've explained, the current role information is > inconsistent, the mapping process will produce a single consistent view of > the current fragmentary information.
But, if the data sources are inconsistent, then you're going to have to reassign the roles of some participants in order to resolve those discrepancies. If the current mappings are inconsistent, then whole roles get reassigned to fit into a single structure. >>> If you could explain where the documentation is unclear we'll see what we >>> can do to clarify it. >> >> Let's start with the 1st sentence of the transition roles document. >> >> "The new website infrastructure will support governance and website >> roles." >> >> This clearly needs clarifying, because we're being told that there are no >> website roles - at least for community groups. (And in the case of >> Projects and User Groups it looks like a governance model without the >> constitutional backing that we should have had.) > > I think you are possibly reading more into that sentence than it was > intended to convey, as the constitutional and community roles are one and > the same, as has been said previously. The constitutional and community roles are fine; it's the website roles (or lack of them) that's the issue. >> Looking at the data migration document, there are at least two obvious >> problems: >> >> 1. It talks about electorate collectives as separate entities. That >> seems to imply >> that the new auth app will be structured according to the new >> constitution. It's >> also inconsistent with the transition roles document. > > There is a 1:1 mapping between the data for CCs in the CGs and the > Electorate data, so the split is mainly just an implementation detail. If you update one, does the other get updated to follow it? > We've kept the Electorate information in a separate place for two reasons, > firstly to ease the transition if the new Constitution or some variant of it > is ever approved. The second reason is so that we can at least partially > devolve the management of CGs to the CGs themselves, so they will be able > to (for example) add their own Cs. However voting rights require OGB > involvement, so that is also a reason why that data has been kept separate. I'm confused. You just said there's a 1:1 mapping, then you say that it's kept separate. Yet I can go into auth and make somebody a Core Contributor - what does that mean? >> 2. Contributors in the new auth app will be seeded both from poll and >> website >> leaders. If that is the case then the Contributor role in the new auth app >> is a >> website role, not a constitutional role. (It can't be a constitutional >> role because >> the constitution requires a specific grant process.) And, as a result, the >> new >> auth app fails to model the constitutional Contributor role. > > Giving someone CC status require OGB assent as there are voting > implications, giving C status doesn't, and the OGB policy document [1] also > restates that. That policy only ensures that section 4.2 of the current constitution is implemented. But the question was about Contributors, not CCs. I'll ask again: does the new auth app store Contributor grants? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ website-discuss mailing list [email protected]
