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
--
_______________________________________________
website-discuss mailing list
[email protected]
