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
From:
<tech-council@ole-lists.openlibraryfoundation.org> on behalf of Jakub Skoczen <jakub@indexdata.com>
Reply-To: "tech-council@ole-lists.openlibraryfoundation.org" <tech-council@ole-lists.openlibraryfoundation.org>
Date: Monday, June 25, 2018 at 8:25 AM
To: "tech-council@ole-lists.openlibraryfoundation.org" <tech-council@ole-lists.openlibraryfoundation.org>
Cc: Mark Veksler <mveksler@ebsco.com>
Subject: Re: additional items for TC's backlog
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
Unmaintained repo (now removed from stripes-smart-components):
https://github.com/folio-org/react-githubish-mentions/pull/4
Experiment module (can this go somewhere else than the folio-org?):
https://github.com/folio-org/ui-datasets/pull/1
Deprecated repos, that contain other deprecations:
https://github.com/folio-org/ui-okapi-console
https://github.com/folio-org/ui-items
https://github.com/folio-org/ui-scan
https://github.com/folio-org/stripes-redux
https://github.com/folio-org/stripes-loader
Code rot hanging around in stripes-core:
https://github.com/folio-org/stripes-core/pull/332
- 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://www.simplelists.com/confirm.php?u=oiqL9fSPwH7CygP7Nc81bAvTlVRxqaFT