...

1. Technical Priorities

2. Bug Prioritization

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

3. F4 GitHub Organizations - "Becoming an fcrepo4-exts project"
4. Ticket review process - who does it?

5. ...

6. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

7. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

...

1. To understand what we are trying to implement and focus on for next 6+ months. Trying to get consensus on the listed priorities. Clustering no longer a medium term priority, but no pickup after some preliminary testing.
   1. Make sure that the difference between #1 (the Fedora API) and #2 & 3 are priorities on the reference implementation of #1. Make sure this is clear on public facing documentation.
   2. Unknown User (escowles@ucsd.edu): Where does bug fixing fit into the technical priorities? Performance scale is an obvious fit but others don't have a clear tie in.
      1. Provides the community as well as developers information on what the "target" is for the community as a whole. Bugs are obviously a priority but may not be required here as a working product should be an assumption.
      2. A way to determine prioritization of issues that may have some support or are difficult to decide
      3. A bug is only a bug because it does not work according to SPEC and expected behaviour.
      4. Different people have different priorities and when they encounter problems, those problems are as important as any other priority on the list.
   3. Consensus with the main services of the Fedora API (priority #1)
      1. Under transactions we need a way for people to efficiently perform a batch of operations against the repository.
      2. Something related to asynchronous event stream to the API?
      3. Unknown User (acoburn): Is whether Fedora publishes some sort of event stream a priority? It does not publish events, it provides events and an external module publishes the events. Distinction between inprocess and out of process work in the repository kernel, currently everything is inprocess and event publishing is an "out of process" action. But ajs6f would not like to add this to the kernel.
         
         1. Andrew Woods: If we did not publish events then a lot of the F4 functionality goes away. A. Soroka: does not feel we lose priority, sometimes things are not as needed as they first appear.
         2. The kernel creates events "in process" and we are committed to an SPI to allow "out of process" publishing of those events.
         3. We have good standards to tie our externally facing processes, but the internally facing processes don't have the same standards. In places where there is no external spec we need to create our own spec and publish it. This makes it something that can be relied on by implementers of Fedora. The reference implementation would naturally produce this SPI for events.
         4. ^^ Makes it clear when a "bug" is a "bug"
            
            
2. Red items should be an immediate priority, green are nice to clean up. Very serious bugs!
   
   
3. Please review the document and make comments on that wiki page.
   
   
4. When Andrew Woods does a ticket, no one reviews them for him. Maybe establish a more formal process to make sure all tickets are reviewed in a timely fashion.
   
   
5. Final questions: A. Soroka: When will the technical priorities document become public? In the next week or so, float by IRC, then leadership team, and finally the broader community.