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. > It's been implied, certainly, but the documentation is unclear (see below). > And we must be changing something because the grants database *isn't* > currently used for access control. The poll information, the portal information and the SCM information are all held in the same database. Although the data is supposed to be internally consistent, in many cases it isn't. The migration and the subsequent cleanup will provide a consistent view of the information. >> 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. > 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. 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. > 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. The current system embodies several different models of the Community, none of them completely accurate. Indeed the current Constitution itself is not an accurate model of the Community, which is exactly why there was an attempt to get the new one approved. We had multiple issues to address as part of the migration. First we had to preserve the current constitutional structures for CGs, whilst not precluding the new Constitution if it is ratified at some point. Next we had to come up with reasonable structures for Ps and UGs, both of which are poorly/not covered in the current Constitution. Then we had to populate the new system from data sources that are fragmentary and inconsistent. Next we had to provide mechanisms to allow new applications to access the data in the new system. And we had to do all that whilst providing the same data to the existing applications which directly access the current database to read/write their various (inconsistent) parts of it. In practice that means that not only do we have to have a forward mapping from the current database into Auth, we also have to have a reverse one as well, so that any changes in Auth get mapped back into the existing database. All those factors severely limit what we can do in practice. As we've said, what we are doing is a migration not a reimplementation of the Community structures, and the form of that transition is largely governed by the constrained environment that we are in. In an ideal world we may well have done some things differently, but that's not the starting point we had. [1] http://wiki.genunix.org/wiki/index.php/OGB_2009/007 -- Alan Burlison --
