Brainstorming about using github labels in the case of ontologies

[DrLeturc]

Hi,

There are lot of issues. It could be interesting to use the labels proposed by github and propose a methodology to use them well for the cases of ontologies.

Here is a first try on the good usage of the labels for the project HyperAgent.

The description of basic labels provided by github are :

• bug : something isn't working (e.g. if there is an inconsistency in the ontology ?)

• documentation : improvements or additions to documentation (e.g. every issues that talk about the core vocabulary ?)

• duplicate : this issue or pull request already exists (e.g. some issues are really closed, it would be useful to indicate when there are several issues related to that one..)

• enhancement : new feature or request (e.g. when a new vocabulary should be added to the ontology ? All the current issues would be labeled with that ?)

• good first issue : good for newcomers (e.g. we would use it to indicate the most relevant issues to understand the choices that we did on the ontology?)

• help wanted : extra attention is needed (e.g. if one user doesn't understand how to use a class/property, very important issue because it would mean that a part of the ontology is maybe ambiguous and should be corrected quickly ?)

• invalid : this doesn't seem right (e.g. an issue that does not follow our standards and is not relevant ??)

• question : further information is requested (e.g. general question ? misunderstanding of the ontology ? What difference with "help wanted" exactly ?)

• wontfix : this will not be worked on (e.g. an issue which is out of scope ?)

Do you see any labels that should be considered additionally in our approach?

PS: this issue is there to ensure the proper use of the labels by the team members.

[DrLeturc]

We added two more labels.

• methodology : to indicate that the issue is related to the methodology of the project

• ontology : to indicate that the issue is related to the ontology

[andreiciortea]

Great! Just one quick question: not sure I understand how we should use the "documentation" label and how it positions to the "ontology" label.

[FabienGandon]

I created the ontology label as an alternative to the methodology one to differentiate issues on the the ontology itself and the ones about the methodology we following ; I imagine both may have document related issues

[andreiciortea]

Thanks @FabienGandon! The distinction between the ontology and methodology labels is clear, but I was wondering how to use the documentation label. The current definition for documentation says: "every issues that talk about the core vocabulary" — but would this then mean any issue related to the ontology (overlaps with the ontology label)? I'm probably misinterpreting the definition for documentation, hence the clarification question.

[DrLeturc]

Good point Andrei. It seems that "documentation" is overlapping with "ontology".

Maybe "documentation" should help to understand the current choices on the HyperAgent ontology and focuses on how to use the HyperAgent ontology while "ontology" is more general and do not talk only about the HyperAgent ontology itself but also others as e.g. Polifonia, ROH, etc. What do you think ?

I'm not super happy with this proposition.

[andreiciortea]

Some quick ideas that come to mind:

• perhaps we could use "documentation" to label issues that focus on natural language definitions (captured in comments and part of the generated documentation)
• in the future, we could also use the "documentation" label for any open specs accompanying the ontology and automatically generated documentation; e.g., this would include any open spec on how to apply the ontology (incl. documentation of software prototypes), documentation of use cases, etc.

[DrLeturc]

OK with that. To sum up : "documentation" -> relates to "any open specs accompanying the ontology and automatically generated documentation; e.g., this would include any open spec on how to apply the ontology (incl. documentation of software prototypes), documentation of use cases, etc." "ontology" -> all discussions about the ontology itself (e.g. questions, enhancement, definitions, bugs, etc.)

Second point, 2 new labels may be considered if we decide to use issues for motivating scenarios https://github.com/HyperAgents/ns.hyperagents.org/issues/74 :

• "motivating scenario" when the issue is a motivating scenario of the ontology

• "valid feature" when the motivating scenario has been accepted as a feature

• "invalid feature" when we reject the motivating scenario

• nothing if it has not been accepted or rejected

A motivating scenario (as an Issue) will be associated to a milestone.

[DrLeturc]

I would add a new thing: it seems labels is an important tool to filter issues. If we decide to use new labels in the future, maybe it would be useful to add a new label e.g. "label issue" ? This would help to propose new labels(or modify, or delete) as well as the way we did it with create/modify/delete motivating scenarios.

[DrLeturc]

Using "invalid" and "invalid story", or "invalid feature" seem a bad idea since it can be ambiguous.

Could we image we use "invalid" for saying that a motivating scenario is "invalid" ? yes, of course. So we need to propose a new label for "invalid story" or use the standard Github "invalid" and adapt the definition of this label.

[DrLeturc]

I removed "invalid story". I think we should either use the label "invalid" or "wontfix". "invalid" would suggest that a motivating scenario does not follow our standard while "wontfix" means that we won't consider it.

I renamed "valid story" to "accepted" to denote a motivating scenario that has been accepted in the project to be implemented.

[DrLeturc]

After discussion at the heartbeat meeting on 16 June 2023, we decided to close this issue in order to focus on other project priorities.