Page Comparison

MarkV, Harry, and I have discussed Prokopovych's lack of development resources. The following plan is what we propose to address the issue. I believe you all have had heard some bits and pieces so I hope the following note provides all the same understanding.

Effective with Lotus release

- Vega takes ownership of these modules: checkin, checkout, requests, circulation, circulation storage, and service points

- Vega will NOT be responsible for

-- Kiwi bugfixes related to the above modules

-- Karate Tests > setting up/implementing initial tests for the above modules. An additional resource will be provided to Prokopovych team to work on these tests.

-- RTL/Jest tests > Vega will not inherit setting up/implementing initial tests for the above modules. An additional resource will be provided to Prokopovych team to work on these tests.

- These two additional resources are to be allocated for tests only.

Holly, Brooks, Marc, and Zak - What we need from you all for a successful transition to Vega.

- By Tuesday, October 5th | Please provide a list of priorities features and bugs related to above modules that must be addressed in Lotus.

- By Thursday, October 14th | Please groom and prioritize entire backlog of issues related to above modules. Identify any issues that should be addressed with the Morning Glory release.

We need to understand priorities because we need to reset Vega's priorities for Lotus.

I will schedule meetings to discuss further. I hope we can complete the gradual transition by November 18th.

20 minutes

At a previous Capacity Planning meeting we decided that we have outgrown the ranking process.  Our plan for identifying work is to...

1. Use the pointing exercise results to prioritize.
2. If a PO doesn't have highly pointed features, that PO should go to the PO group to see if they can take on a highly pointed feature for another PO. 
3. If #2 above doesn't resolve the issue, the PO should talk to the Capacity Planning Team. 

Issues to address:  

1. How does a site make it clear that a feature is a "showstopper" for them.  We could continue applying a Label of "Cornell-showstopper", "TAMU-showstopper", etc. or we could create a multi-select field called "Showstopper for".  (The drop-down for "Showstopper for" will include all sites.  The only issue I have with this is this approach is that an editor would need to make sure the other institutions aren't de-selected when they select their institution.)  Keep using the Label approach.  Candidates must be identified 6 months prior to release. 
2. Should we allow sites that have already ranked features to keep their ranks in JIRA?  (We would remove the rank fields for sites that never actually ranked features.)  Leave them there for now, and revisit in a quarter.  Remove the sites that have not ranked anything, letting them know in advance.  Harry will being up date selection with the PC.

20 minutes

Should we redo the pointing exercise?  Options -

1) We haven't finished the top features of the Kiwi pointing exercise, so we should continue on with them.

2) We could re-open the Kiwi pointing exercise spreadsheet for new institutions to participate and old institutions to make changes if needed. 

3) Re-do the whole exercise for everyone.  Harry will ask PC how often we should do this.  Every year seems best.

Background:  Originally we called this the "Kiwi pointing exercise" because we thought we would be doing pointing for every release.  When we saw the results of the "Kiwi pointing exercise" it became clear that we will not be able to implement all of the highest pointed features within one release, so it isn't appropriate to do pointing for every release.  Instead, it makes more sense to do pointing after we have completed some of the existing highly pointed features.  We have not done that.