* Alan Burlison <Alan.Burlison at sun.com> [2007-12-03 22:19]: > Stephen Hahn wrote: > > >>The problem we have is that we have no reliable way of identifying Sun > >>employees in the current OSO database. There is a employee_id column, > >>but there's nothing to check it is filled in correctly, or even at all. > >>Email addresses are no use either. And if we don't mandate that SWAN > >>and OSO usernames are the same, the problem gets even harder still. > > > > I'm not sure what the problem is: ON (and other consolidations) > > should not be granting commit rights to a user without either a > > contributor agreement or a membership in an organization with a > > contributor agreement. Has a consolidation done so? > > I'm not suggesting that this has happened, but as far as I know there is > currently no mandatory checking of SCAs prior to commit, either manual > or automatic. because all commits are proxied by a sponsor, we have > traceability and we are depending on the sponsor to do the checks, but > as far as I know it is not enforced. Once the gate moves outside we > will need such checks to be automated, otherwise the manual burden will > become unreasonable. > > We also have the issue of who actually grants commit rights - is this > going to be by a central body, or are the GCs and projects that make up > ON going to manage their own committers? Both. I've been warning projects that seek to integrate into a consolidation that they need to ensure that they have SCAs in place for non-Sun employees. Cleaning this up further, as you and Rich have mentioned earlier in the thread, so that various transitions are covered correctly seems great. Helping the project and consolidation leads in filtering for valid SCA-possessing individuals sounds very valuable.
> > (I am assuming that the employee_id is only editable by site > > administrators, and is presumed valid.) > > It is a user-editable field in the current system. I'm not intending in > replicating that in the new system, but when we migrate we will have to > validate/insert the correct values for all migrated users, and we need a > process to ensuring that the data stays in step with reality, e.g. when > people leave/join. Please. Although we have good knowledge about Sun contributors, there will be other individuals contributing under other organizational agreements--that suggests that employee ID might need to be "unique string for this organizational agreement", and that that might need to be a field whose modification access is given over to a specific assignee (from the contributing organization, I guess). - Stephen -- sch at sun.com http://blogs.sun.com/sch/
