Agenda

Day 1

  1. Tag 0.5? 0.5-alpha? 0.5-demo?
  2. Grouper and group integration topics
    1. Talk to Grouper folks about COmanage Registry/Grouper integration (side meeting?)
    2. What should be used as the Subject in Grouper? "What goes into a Grouper group?" email
    3. Change ID to UUID for group/group member? "change to table column definitions for groups" email
    4. Review Scott's "on COs, COUs, and groups" email... federated group enrollment?
    5. Grouper DataSource rethink
  3. Sprint and Release Planning to get to 1.0 for the fall member meeting
  4. Review weekly calls schedule (scrum + dev call)
  5. Steve onboarding?
    1. SOW
    2. Tasks
    3. Access to stuff (wiki, svn, jira, mailing lists)
  6. Schedule next f2f

Day 2

  1. Review Scott's "requirements to translate" email
  2. LDAP Provisioning design
  3. UI review
    1. Color schemes
    2. AJAXy stuff
    3. Next steps for improvements
    4. Review moving logic into new pageTitle element (see email "JIRA Updated: (CO-221) Body theme")
    5. Scaling up the UI
      1. Load up current LIGO population and see what breaks? Or how usable it is?
  4. Logging and audit (CO-42)
  5. RFE Process (how to submit, approve, etc)
  6. Source repository management strategies
  7. Identifier Mapping requirements
  8. Sprint 06 Planning and 0.6 Roadmap Review

Notes

  1. Tag 0.5? 0.5-alpha? 0.5-demo?
    • will tag after meeting
  2. Grouper and group integration topics
    • new requirements for Grouper Dev Team:
      • auto incrementing integer as an attribute type (Need to talk more)
      • need to be able to search by value in specific attribute space (Scott to add an RFE)
      • ability to assign multiple attrib values in one web service call (Scott to add an RFE)
    • COmanage ticket
      • stop using recursive around where group (code change)
      • support to create views for grouper and LDAP as part of database setup
    • Preferred deployment option is that if you're going to use grouper, you should set it up to get its source directly out of COmanage
    • Item for WG agenda - Scott showing off current state of grouper integration
  3. Sprint 06 Planning and 0.6 Roadmap Review
    • sprint06 ends May 25; .6 scheduled to release May 31
    • want to aim for a 1.0 release for fall member meeting, and if 1.0 is largely PR oriented but also reasonably usable, that gives us a fair amount of leeway as to what goes in to it; so, we don't have every feature in the enrollment flow done, but we can do a lot
    • This would mean about 1 release a month, and based on our track record
      • .6 - Grouper integration, LDAP provisioning (this would allow an initial deployment at LIGO), continued UI evolution, enrollment via invitation
      • .7 - enrollment
      • .8 - kerberos provisioning
      • .9 - notifications, minimal reporting
      • 1.0 - audit, CO person integration, UI scaling to 1000; Directory .2 or .3
        **need grouper integration, provisioning into LDAP, configurable notification method centered around emails, multiple workflows defined and configurable (sponsorship notion is positive), NSF demographics reporting, Directory has to be minimally active, minimal reconciliation (already implemented), other provisioning (kerberos principle), password management plugin (probably just for LIGO), audit would be nice-to-have but not req for 1.0; scale to 1000 people
  4. Review Scott's "requirements to translate" email (sent to COmanage-dev 16-March)
      • set an effective membership date for in the future, and be able to pre-populate specific attributes such as FTE - so, extended attributes plus a start date. already done
      • an extended attribute or attributes applicable only to a certain type of individual; this will be difficult because while we can limit/require during enrollment process, but after that, all attributes are available/viewable to all people; perhaps apply a filter based on certain attributes, maybe role; maybe show configured attribute on a per-affiliation-type basis
      • new reporting requirement: FTE, status info available for LSC members' request in roster.ligo.org. (Does this request comply with privacy laws?)
      • Expiration dates for membership - DONE
      • category for short term grad students - this will be just another role
      • reporting requirement: if there is going to be more than 3 returned rows, the rows will be numbered (cake loves to do that, so this shouldn't be a problem)
      • reporting requirement: reporting function, custom, that applies a very specific LIGO algorithm to the effective dates of memberships and particular set of extended attributes
      • audit requirement: membership history function; need to see membership changes back in time; this is a dependency on reporting
      • proxy members for votes: this is an app requirement; delegation/authZ problem ( to go in the "future" bucket)
      • reporting/notification function that automatically e-mails sent out 2-4 times a year requesting PIs to update their rosters with a report of roster, demographics, council members, and author list
  5. Scaling up the UI
    • Load up current LIGO population and see what breaks? Or how usable it is?
    • will need a search button to really do this
    • Logging and audit (CO-42)
  6. RFE Process (how to submit, approve, etc)
    • tell people to send email to community list
  7. Identifier Mapping requirements
    • need to figure this out for provisioning, so we LIGO to say "for provisioning to happen, we need the following identifiers"; during the process, you will be giving them a name (or they enter it), LIGO has an algorithm that will let LIGO assign the identifier based on that name, turns it in to an ascii-fied username of the format first.last and that is prepended to @LIGO.ORG and that becomes their identifier; will filter on the length of that combination eventually; if there is already a first.last, then they go through a series of possibilities until a unique identifier is found; identifiers must be permanently unique; username is first.last, eppn is first.last@ligo.org, and the kern principle is first.last@LIGO.ORG, and these all need to come out of provisioning, and all three will go in LDAP; these get attached to the CO person identifier; employee number needs to be auto generated, guaranteed unique (it only has utility to make sure we have a disambiguous way to refer to someone for all time)
  • No labels