Any way to sync JIRA tickets and GitHub Issues? (would be necessary if we wanted to continue to use both tools for time being)
No way to do this easily (without paying for an expensive plugin/tool)
Any way to embed GitHub issue information into Confluence Wiki (in same manner as JIRA tickets)? For example, this feature in JIRA helps auto-create our Changes in 6.x in documentation.
Also able to auto-generate Release Notes (in markdown format) using https://github.com/github-tools/github-release-notes (Would allow us to post changelogs/release notes in GitHub directly instead of on the Wiki)
Finalize / approve the initial list of all authorization features which we should implement for the/api/authz/features REST endpoint. This list of features should be limited to only features which are required to enable/disable User Interface functionality.(In other words, we can always add more features in the future. We just need to approve the list necessary for 7.0)
Art Lowel (Atmire) : I don't see any immediate issues with the current set of features, but I would prefer a consistent naming scheme. I'd use canDoSomething for everything
Tim Donohue added possible renames of these features based on Art's idea (see cell comments in spreadsheet). I like the "can[DoSomething]" naming scheme as well.
Proposal from Art Lowel (Atmire)on enhancing object cache in Angular UI.
Initial Performance Testing from Chris. Needs revisiting / retesting prior to 7.0.
These performance tests were run prior to the work on "projections" (to limit the data returned by the REST API). Therefore, it is likely performance is much improved, but needs verification testing.
Delayed. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior. Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata. Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.
Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question. May allow for more CMS-lite behavior in the future
Timeline for this is uncertain. Possibly in 7 or 8. May depend on how/whether it can be scoped.