Establish an overall data flow for curators to correct/challenge/remove annotations as traceable issues

[selewis]

Proposal/requirements needs to be made.

[ValWood]

We have a reasonable system. MAybe it could improve, but we can probably close this?

[pgaudet]

Sure. This is probably a ticket in some of the Noctua trackers.

[deustp01]

This is probably a ticket in some of the Noctua trackers.

So the issue doesn't get lost again, could you find the Noctua tickets and link them to this one?

[ValWood]

I thought this tracker was the place to document annotation issues in a traceable way?

[pgaudet]

@deustp01 https://github.com/geneontology/noctua/issues/361

[deustp01]

I wonder if some combination of @pgaudet @ValWood and other interested people actively working on the ontology structure could come up with a plan to present at the October 2023 GO Consortium meeting.

One thought from here is that every new ticket should come with a clock for maximum permissible times

• from when an issue is created and it is assigned to a person who can work on it (and the assignment is accepted)
• from when it is assigned to when an action is taken, with each action resetting this clock. Action can include a posting that summarizes progress short of resolving the issue A possible time for the clock is a few weeks, and any ticket that runs out its time without action is automatically closed. When an issue requires re-curation by participating groups, that starts a separate clock with perhaps a longer time but again mandated followup.

This is procrustean but that is the point: if resolvable issues linger the result is confusion and duplicate work; sometimes creating a ticket is the best way to discover whether an issue can be resolved by available people with available tools.

[ValWood]

This ticket was originally about annotation issues, but the comment above seems to be about ontology structure?

From a personal perspective, implementing such a system might even be a bigger drain on already severely limited resources and result in even more tickets in people's inboxes. Active ontology developers apart from @pgaudet are only working ~1 day per week. That isn't very much time to make a dent in >700 open tracker tickets. Although a large number of the tickets are closed quickly, the ones which remain are usually more difficult to address. However, they are grouped into projects so redundant tickets are usually spotted and closed.

I remember the days when there more than 4+ full time ontology developers and probably fewer new tickets. Now that would be an interesting graph......

[deustp01]

the comment above seems to be about ontology structure?

It is intended to be a comment about dealing with annotation issues in a more organized way. And the really crucial point is that, while flagging problems is a Good Thing, adding more to a pile that is already disorganized and too big to handle, in the absence of any practical way to limit and direct the needed work, is destructive. Asking the individuals who originate an issue to do work in advance to figure out what kind of effort is likely needed to resolve it, and who will make that effort, is hard but I don't see an alternative.

(But it applies to ontology structure requests too.)

[ValWood]

For the annotation tracker it's a bit different. Most of the new ticket are resolved in a timely manner by the assignee. there is a good system in place for this.

The legacy tickets are the problem, I guess we could just close them all but many seem to be in progress or forgotten, or unassigned, hence me prompting people last week. This resulted in the closure of >100 tickets (i.e. over 25% of the tracker).

Another round of prompting in a month or so, we might be able to close most of the legacy tickets. However, that depends entirely on the assignees answering the questions or making the required fixes.....

These are the annotation tracker tickets which have a designated pathway to fix them: is:issue -label:"annotation review" is:open -label:"InterPro mapping" -label:"PAINT annotation" -label:"UniProt KW2GO mapping" -label:ARBA -label:UniRule -label:"EC2GO mapping" -label:GO-CAM -label:UniProt -label:GPAD/GPI -assignee:pgaudet

..after removing these,

There are now only 108 tickets which still need follow up https://github.com/geneontology/go-annotation/issues?q=is%3Aissue+-label%3A%22annotation+review%22+is%3Aopen+-label%3A%22InterPro+mapping%22+-label%3A%22PAINT+annotation%22+-label%3A%22UniProt+KW2GO+mapping%22+-label%3AARBA+-label%3AUniRule+-label%3A%22EC2GO+mapping%22+-label%3AGO-CAM+-label%3AUniProt+-label%3AGPAD%2FGPI+-assignee%3Apgaudet+

either to be assigned to someone, or reassigned , or closed. These are mainly for individual annotation fixes by various databases , and they seem to sometimes get forgotten about, or the person has left, of forgotten to close. Once I have another free evening I will go through the remainder, and after that we should be good going forward if GO assigns somebody to keep an eye on the tracker, and maybe as you suggest some sort of periodic automated reminder. (but this will only work if the ticket is assigned to an active person).