The first part of discussion I’d like to have is about how we review a feature like this. The reporting SIG should define the feature, but – it’s a key part of core
functionality, tying into OKAPI as it does, therefore I’d think it would be good for TC to weigh in on it. This would be a first for us as a TC so I think be good to have few mins discussion of how we go about this type of review…what are the boundaries for
TC vs SIG etc.
Then following that I think it would be good for TC to weigh in on the design itself - is the model for OKAPI extraction and message queue agreed up by everyone. Because
it’s at a key architectural point in the system I just want to be sure everyone is in agreement before we implement it. I thought I heard some comments at Wolfcon that the previous PoC was not aligned with how some would have done it, so I want to double
check we are ok on it. Maybe I misunderstood that and we are all ok with the design laid out here, in which case that would be a quick conversation.
Also – this EPIC mixes Analytics and Auditing. Should we separate it? I think we should for clarity at least, and maybe for implementation as well if we need to spread
it across teams. Last item for discussion would be that the EPIC includes implementation details (although not yet assigned or completed) for data warehouse and reporting dashboards. Those may be outside the definition of “core” so again how do we want to
handle this part, not clear to me who does this part for example and how far we go with it.
You can see I’m probably mixing some issues appropriate for TC with some appropriate for the SIG, that may be part of the exercise, unless it’s just me unsure of this.
Lastly then – do we have a location for TC agenda backlog, or should we start that in Jira or some other means of organizing for community to see, Trello for example
if not Jira?
VP Development - EBSCO Information Services
CAUTION: This
email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I think Stripes-core and Stripes-smart-components issues are best handled on the Stripes Architecture
meeting, what do you think Zak?
As far as deprecated and experimental repos goes -- it would be good to have a dedicated space on GH
for those but I don't think any such thing is possible with GitHub? If not, maybe prefixing the repos would work?
As discussed in our Thursday meeting, here are some additional (some are time-sensitive) items to be included in our
work backlog. They are not listed in any particular order, but we will probably need to get into the habit of regularly prioritizing our backlog and ensure it is visible to the rest of the community:
- Process for triaging issues and assigning PR ownership with turnaround expectations (SLAs?)
- Process for end of lifing a repo when there is no point in maintaining it
- Review of the Stripes architecture
- Stripes testing -- updating the Definition Of Done (e.g., ensuring that stripes tests are developed)
- Making changes to the PR process by running a simple build on the PR
(prob
to be included in the Definition of Done)
- CI builds: Travis vs Jenkins
Director, FOLIO Development - EBSCO Information Services
To unsubscribe from this list please go to http://archives.simplelists.com
To unsubscribe from this list please go to http://archives.simplelists.com
To unsubscribe from this list please go to http://archives.simplelists.com