Is there a documented design upon which this Epic would be executed?

Could someone (Jakub?) describe how this epic relates to the Platform or LSP Core architecture? Are there architectural decisions that need to be made or assumptions about what the Platform or Core provide on which this epic depends? Not having been part of earlier conversations it’s hard for me to appreciate “it’s a key part of core functionality, tying into OKAPI as it does,” and ” 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"

The Epic discussions both Audit and Analytics reporting. I agree that we should discuss whether these should be separated.

-mdg


On Jun 25, 2018, at 8:16 AM, Michael Gunning <mgunning@ebsco.com> wrote:

Hi Folks, I’d like to add an agenda item for discussion of UXPROD—330: Reporting: Analytics and Audit Data Logging for External Reporting.  Likely EBSCO will take this one on and contribute to community, adding engineering to it next month.  This will be a proposed part of the plan to be ratified w/ Product Council once the current capacity planning and gap analysis is complete.
 
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?
 
Thanks
Mike
 
Mike Gunning
VP Development - EBSCO Information Services
mgunning@ebsco.com | +1-520-429-1661 (m)
 
 
 
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.
 
Mark, 
 
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?
 
On Sun, Jun 24, 2018 at 8:31 PM Mark Veksler <mveksler@ebsco.com> wrote:
Good day everyone!
 
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:
 
  • Repo management
    • 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
 
 
 
-- 
Mark Veksler
Director, FOLIO Development - EBSCO Information Services
mveksler@ebsco.com | +1-978-356-6500 x2349 (O) | +1-617-470-5453 (m)
 

To unsubscribe from this list please go to http://archives.simplelists.com


 
-- 
-- 
Regards,
Jakub Skoczen

To unsubscribe from this list please go to http://archives.simplelists.com

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=SeK0ArgpLZB2ijVHc1q8eivZ4CXy8J2w