Hi Raff Sorry for delay in responding. While I appreciate the thoughtfulness of the work you and Elli have put into this, I am not certain that we're likely to be able to keep up with such a complicated label set, particularly if you're expecting tickets to be categorised when they are created. On 13/12/15 21:59, Raffaele Viglianti wrote:

For example a new ticket about a badly misguiding example for the the "div" element would probably get these labels:

"Component: Core schema"

What does "component" mean here? The "core" is the name of a TEI module, and <div> is actually not defined there but in textstructure, so I guess you mean "core schema" in some other sense. But what? And what about things that are proposals for new elements or modules? What component do they go in?

"Type: Bug" Is a "misleading example" really a "bug" ? "Priority: High" I suppose this is clear enough, but whose priorities are we talking about? "Status: Needs Discussion"

Is this the same as the old Red/Amber/Green ? If so, why change it?

There are a couple of extra labels that don't fit this system: - "sf-automigrated": identifies tickets migrated from SF. We suggest to keep it. Why is that useful? I would have thought the date would do to indicate it, if needed. - "SIG": identifies tickets about SIG organization (maybe we need a category for less technical discussions, "meta"?).

SIG is fine by me. "Meta" has a different signification for me: I'd expect it to label tickets which are about ODD for example.

Then we have a couple of specific questions for you: - Should we keep labels specific to each chapter in the guidelines? (e.g. MS, ND, PH, etc). We think they should go away. But if we keep them we can get group them under "Component: Guidelines", e.g. "Component: Guidelines: MS".

Those labels were created during the run up to P5. They weren't used much then, and I don't think they're much use now. Nuke em. But now I am puzzled again about what you mean by "component". We are only talking about the Guidelines, aren't we? So how come it's a component?

- "sf_creator-*" tickets were introduced to facilitate finding migrated tickets by their original SF creator. Since that information is also recorded in the text of the ticket, we think they should go away. Thoughts?

Remove them: fine by me

On 14/12/15 01:36, Raffaele Viglianti wrote:

...

What does "component" mean here? The "core" is the name of a TEI module, and <div> is actually not defined there but in textstructure, so I guess you mean "core schema" in some other sense. But what? And what about things that are proposals for new elements or modules? What component do they go in? Point taken. By core we mean "principal", "main", not the module. It is as opposed to any customization schema. We could say "Component: main schema" instead, or "Component: TEI all".

I think it is the 'Component' bit that people might find confusing. TEI all sounds like tei_all the general schema, will that cause confusion. I'm assuming what you mean is "The component this bug/fr is talking about is the main TEI scheme generally".

...

"Status: Needs Discussion" Is this the same as the old Red/Amber/Green ? If so, why change it? It is, and we changed these names during out F2F, in fact. I think they are clearer than Red/Amber/Green, but I'm also fine with keeping the old names.

I don't mind the rename, but would suggest we keep the colours associated with this (i.e. 'Needs Discussion' should be an amber coloured label, 'Blocked' should be red, 'Go' should be green, etc.) I believe this was your intention, I just thought I'd reiterate it.

...

- "SIG": identifies tickets about SIG organization (maybe we need a

...

category for less technical discussions, "meta"?). SIG is fine by me. "Meta" has a different signification for me: I'd expect it to label tickets which are about ODD for example.

SIG for any SIG related activities, including looking at proposals from a SIG.

...

Then we have a couple of specific questions for you:

...

- Should we keep labels specific to each chapter in the guidelines? (e.g. MS, ND, PH, etc). We think they should go away. But if we keep them we can get group them under "Component: Guidelines", e.g. "Component: Guidelines: MS".

Those labels were created during the run up to P5. They weren't used much then, and I don't think they're much use now. Nuke em. Agreed - Nuke'em.

By component we mean one of our points of focus for development; e.g. the Guidelines (prose issues, mostly), the "main" schema development (things that we'd fix in the ODD, mostly), tools (things that should be moved to the Stylesheet repo, or are related to some other tool we maintain). Thanks again for your comments - looking forward to more discussion. Best, Raff

Isn't that handled by having the different repositories? Re: sf_creator* Embed in prose, remove categories. Hope that helps, -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

On 14/12/15 13:07, Raffaele Viglianti wrote:

That is what we meant. What would be a good short label for this?

What about Component: TEI Guidelines vs Component: TEI Schema?

...

Isn't that handled by having the different repositories?

Only the stylesheets, but not other "tools" like Jenkins and Roma. I'd still keep a label for Stylesheets as a signifier that the issue should be moved.

Then I'd say something just like the name of the repository it should be moved to. Oh, and there is a Roma repository (and maybe there should be a jenkins one?) -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

On Mon, Dec 14, 2015 at 10:30 AM, Lou Burnard wrote:

On 14/12/15 13:30, James Cummings wrote:

...

On 14/12/15 13:07, Raffaele Viglianti wrote:

...

That is what we meant. What would be a good short label for this?

What about Component: TEI Guidelines vs Component: TEI Schema?

Except that any issue affecting the "TEI schema" (whatever that is) ought ipso facto to be affecting the TEI Guidelines prose (tho admittedly not necessarily vice versa)! When we e.g. add a new element, which is that? Or is it both i.e. two issues? I can see the advantage of distinguishing issues that relate purely to P5 from those that relate to (say) bugs in Roma, but I don't see the advantage of distinguishing aspects of P5.

I agree that issues affecting the TEI schema and the TEI Guidelines are often related, but that doesn't mean that they'll always be in the same ticket. As you said there are Guidelines issues that do not effect the schema, and I'd say that the opposite is true as well: it happens that the Guidelines say something and the schema doesn't do it (because of an oversight). I would also argue for creating two tickets when a change in both the schema and the guidelines is required. It is two different actions (even when strictly related) and may very well be done in two commits. Now, enforcing this would be crazy, but it makes perfect sense to just stick both labels to one issue when this happens. And I'd say that this would not happen very often, but if facts will prove me wrong, we can always merge the two labels into one later on.

...

...

Isn't that handled by having the different repositories?

Only the stylesheets, but not other "tools" like Jenkins and Roma. I'd still keep a label for Stylesheets as a signifier that the issue should be moved.

Agreed that this is useful.

...

...

Then I'd say something just like the name of the repository it should be moved to.

Oh, and there is a Roma repository (and maybe there should be a jenkins one?)

Agree with Jas here.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

No need to be sorry, Lou, as I agree with you. But surely you know that we'll have tickets that *only* affect either the schema or the guidelines (and not both). Because we're human, hence forgetful, busy, etc. Maybe let's talk about scenarios. You mentioned one where a new element is requested. Definitely, that will require changes to the schema and the guidelines, so both labels are assigned. Another scenario is us noticing an inconsistency between guidelines and schema (I've been here for merely a year, but this seems a common situation to me). We write a ticket for this inconsistency and we label the component affected. Another scenario is me having half hour spare to work on tickets; not enough to do anything complicated, but happy to fix some prose here and there; let's see what tickets are open that only require changes to the Guidelines... it would be nice if there were a label for that, no? If the last two scenarios seem too farfetched, I'll back off. On Mon, Dec 14, 2015 at 10:45 AM, Lou Burnard wrote:

Well, sorry Raff, but I disagree. Every change to TEI P5 potentially affects both the schema and the Guidelines prose, and I think separating out these two aspects would just encourage us to fix one but not the other.

But I do agree that "enforcing this would be crazy"!

On 14/12/15 15:40, Raffaele Viglianti wrote:

...

On Mon, Dec 14, 2015 at 10:30 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

On 14/12/15 13:30, James Cummings wrote:

...

On 14/12/15 13:07, Raffaele Viglianti wrote:

...

That is what we meant. What would be a good short label for this?

...

What about Component: TEI Guidelines vs Component: TEI Schema?

Except that any issue affecting the "TEI schema" (whatever that is)

ought ipso facto to be affecting the TEI Guidelines prose (tho admittedly not necessarily vice versa)! When we e.g. add a new element, which is that? Or is it both i.e. two issues? I can see the advantage of distinguishing issues that relate purely to P5 from those that relate to (say) bugs in Roma, but I don't see the advantage of distinguishing aspects of P5.

I agree that issues affecting the TEI schema and the TEI Guidelines are often related, but that doesn't mean that they'll always be in the same ticket. As you said there are Guidelines issues that do not effect the schema, and I'd say that the opposite is true as well: it happens that the Guidelines say something and the schema doesn't do it (because of an oversight).

I would also argue for creating two tickets when a change in both the schema and the guidelines is required. It is two different actions (even when strictly related) and may very well be done in two commits. Now, enforcing this would be crazy, but it makes perfect sense to just stick both labels to one issue when this happens. And I'd say that this would not happen very often, but if facts will prove me wrong, we can always merge the two labels into one later on.

...

Isn't that handled by having the different repositories?

...

...

Only the stylesheets, but not other "tools" like Jenkins and Roma. I'd still keep a label for Stylesheets as a signifier that the issue should be moved.

Agreed that this is useful.

Then I'd say something just like the name of the repository it should be

...

moved to.

Oh, and there is a Roma repository (and maybe there should be a jenkins one?)

Agree with Jas here.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

I think that the first 3 types of tag (Priority, Status and Type) are relatively uncontroversial, is this correct? Priority: High Priority: Low Priority: Medium Status: Blocked Status: Go Status: Needs Discussion Status: Postponed for P6 Status: Wontfix Type: Bug Type: Feature Request And that the Component/Tool/SIG category is more problematic. Component: Core Schema ---suggest moving to Component: TEI Schema Component: Guidelines & Documentation Component: ODD Component: Website Tool: Jenkins Tool: Oxgarage Tool: Oxygen Tool: Roma Tool: Stylesheets SIG In a sense, the tags are for the submitter of the FR or Bug to allow us to understand what they are talking about, and also helping us do some quick sorting. They may be a sign that the issue has to be moved somewhere else, and that's quite useful. These tags are derived from existing ones that submitters used It's very useful to work on the vocabulary in order t make it clearer, and perhaps some larger categories within Tools or Component. thanks, --elli On Mon, Dec 14, 2015 at 11:14 AM, Martin Holmes wrote:

Hi Raff,

I like your last scenario; it's an obvious one for new Council members to get involved with. In fact, I'd argue that prose-fixing-only tickets should be left for new Council members to deal with precisely so they get comfortable with the editing process and git.

Cheers, Martin

On 15-12-14 07:53 AM, Raffaele Viglianti wrote:

...

No need to be sorry, Lou, as I agree with you. But surely you know that we'll have tickets that *only* affect either the schema or the guidelines (and not both). Because we're human, hence forgetful, busy, etc.

Maybe let's talk about scenarios. You mentioned one where a new element is requested. Definitely, that will require changes to the schema and the guidelines, so both labels are assigned.

Another scenario is us noticing an inconsistency between guidelines and schema (I've been here for merely a year, but this seems a common situation to me). We write a ticket for this inconsistency and we label the component affected.

Another scenario is me having half hour spare to work on tickets; not enough to do anything complicated, but happy to fix some prose here and there; let's see what tickets are open that only require changes to the Guidelines... it would be nice if there were a label for that, no?

If the last two scenarios seem too farfetched, I'll back off.

On Mon, Dec 14, 2015 at 10:45 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

Well, sorry Raff, but I disagree. Every change to TEI P5 potentially

...

affects both the schema and the Guidelines prose, and I think separating out these two aspects would just encourage us to fix one but not the other.

But I do agree that "enforcing this would be crazy"!

On 14/12/15 15:40, Raffaele Viglianti wrote:

On Mon, Dec 14, 2015 at 10:30 AM, Lou Burnard <

...

lou.burnard@retired.ox.ac.uk> wrote:

On 14/12/15 13:30, James Cummings wrote:

...

On 14/12/15 13:07, Raffaele Viglianti wrote:

...

That is what we meant. What would be a good short label for this?

> > What about Component: TEI Guidelines vs Component: TEI Schema? >

Except that any issue affecting the "TEI schema" (whatever that is)

ought ipso facto to be affecting the TEI Guidelines prose (tho admittedly not necessarily vice versa)! When we e.g. add a new element, which is that? Or is it both i.e. two issues? I can see the advantage of distinguishing issues that relate purely to P5 from those that relate to (say) bugs in Roma, but I don't see the advantage of distinguishing aspects of P5.

I agree that issues affecting the TEI schema and the TEI Guidelines are often related, but that doesn't mean that they'll always be in the same ticket. As you said there are Guidelines issues that do not effect the schema, and I'd say that the opposite is true as well: it happens that the Guidelines say something and the schema doesn't do it (because of an oversight).

I would also argue for creating two tickets when a change in both the schema and the guidelines is required. It is two different actions (even when strictly related) and may very well be done in two commits. Now, enforcing this would be crazy, but it makes perfect sense to just stick both labels to one issue when this happens. And I'd say that this would not happen very often, but if facts will prove me wrong, we can always merge the two labels into one later on.

Isn't that handled by having the different repositories?

...

...

> Only the stylesheets, but not other "tools" like Jenkins and Roma. > I'd > still keep a label for Stylesheets as a signifier that the issue > should be > moved. > > Agreed that this is useful. >

Then I'd say something just like the name of the repository it should be

...

moved to.

Oh, and there is a Roma repository (and maybe there should be a jenkins one?)

Agree with Jas here.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

--

tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

This all makes sense to me. Perhaps the missing part right now is a clear statement of who is supposed to apply and verify these labels, at what stage. I would suggest: 1. When a Council member creates a ticket, they should do their best to apply all the correct labels. 2. When a ticket is created by a non-Council-member, any Council member who notices and has the time should go and check or assign the labelling. 3. When the Chair is triaging tickets before meetings, he/she should check and correct the labels for any tickets which have not yet been assigned. As I was typing this I had a deja-vu sense that I've typed something very similar before, so perhaps we already discussed this at the FtF or in a telco? Cheers, Martin On 15-12-14 08:28 AM, Mylonas, Elli wrote:

I think that the first 3 types of tag (Priority, Status and Type) are relatively uncontroversial, is this correct?

Priority: High Priority: Low Priority: Medium

Status: Blocked Status: Go Status: Needs Discussion Status: Postponed for P6 Status: Wontfix

Type: Bug Type: Feature Request

And that the Component/Tool/SIG category is more problematic.

Component: Core Schema ---suggest moving to Component: TEI Schema Component: Guidelines & Documentation Component: ODD Component: Website Tool: Jenkins Tool: Oxgarage Tool: Oxygen Tool: Roma Tool: Stylesheets

SIG

In a sense, the tags are for the submitter of the FR or Bug to allow us to understand what they are talking about, and also helping us do some quick sorting. They may be a sign that the issue has to be moved somewhere else, and that's quite useful. These tags are derived from existing ones that submitters used

It's very useful to work on the vocabulary in order t make it clearer, and perhaps some larger categories within Tools or Component.

thanks, --elli

On Mon, Dec 14, 2015 at 11:14 AM, Martin Holmes wrote:

...

Hi Raff,

I like your last scenario; it's an obvious one for new Council members to get involved with. In fact, I'd argue that prose-fixing-only tickets should be left for new Council members to deal with precisely so they get comfortable with the editing process and git.

Cheers, Martin

On 15-12-14 07:53 AM, Raffaele Viglianti wrote:

...

No need to be sorry, Lou, as I agree with you. But surely you know that we'll have tickets that *only* affect either the schema or the guidelines (and not both). Because we're human, hence forgetful, busy, etc.

Maybe let's talk about scenarios. You mentioned one where a new element is requested. Definitely, that will require changes to the schema and the guidelines, so both labels are assigned.

Another scenario is us noticing an inconsistency between guidelines and schema (I've been here for merely a year, but this seems a common situation to me). We write a ticket for this inconsistency and we label the component affected.

Another scenario is me having half hour spare to work on tickets; not enough to do anything complicated, but happy to fix some prose here and there; let's see what tickets are open that only require changes to the Guidelines... it would be nice if there were a label for that, no?

If the last two scenarios seem too farfetched, I'll back off.

On Mon, Dec 14, 2015 at 10:45 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

Well, sorry Raff, but I disagree. Every change to TEI P5 potentially

...

affects both the schema and the Guidelines prose, and I think separating out these two aspects would just encourage us to fix one but not the other.

But I do agree that "enforcing this would be crazy"!

On 14/12/15 15:40, Raffaele Viglianti wrote:

On Mon, Dec 14, 2015 at 10:30 AM, Lou Burnard <

...

lou.burnard@retired.ox.ac.uk> wrote:

On 14/12/15 13:30, James Cummings wrote:

...

On 14/12/15 13:07, Raffaele Viglianti wrote:

> > That is what we meant. What would be a good short label for this? > >> >> What about Component: TEI Guidelines vs Component: TEI Schema? >> > > Except that any issue affecting the "TEI schema" (whatever that is) > ought ipso facto to be affecting the TEI Guidelines prose (tho admittedly not necessarily vice versa)! When we e.g. add a new element, which is that? Or is it both i.e. two issues? I can see the advantage of distinguishing issues that relate purely to P5 from those that relate to (say) bugs in Roma, but I don't see the advantage of distinguishing aspects of P5.

I agree that issues affecting the TEI schema and the TEI Guidelines are often related, but that doesn't mean that they'll always be in the same ticket. As you said there are Guidelines issues that do not effect the schema, and I'd say that the opposite is true as well: it happens that the Guidelines say something and the schema doesn't do it (because of an oversight).

I would also argue for creating two tickets when a change in both the schema and the guidelines is required. It is two different actions (even when strictly related) and may very well be done in two commits. Now, enforcing this would be crazy, but it makes perfect sense to just stick both labels to one issue when this happens. And I'd say that this would not happen very often, but if facts will prove me wrong, we can always merge the two labels into one later on.

Isn't that handled by having the different repositories?

...

> >> Only the stylesheets, but not other "tools" like Jenkins and Roma. >> I'd >> still keep a label for Stylesheets as a signifier that the issue >> should be >> moved. >> >> Agreed that this is useful. >> >

Then I'd say something just like the name of the repository it should be

> moved to. > > Oh, and there is a Roma repository (and maybe there should be a > jenkins > one?) > > Agree with Jas here. >

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

--

tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

That has certainly been our practice hitherto, with the somewhat mixed results we are now trying to rectify! On 14/12/15 17:11, Raffaele Viglianti wrote:

Martin, that seems perfect to me.

FWIW, only contributors can assign labels, so tickets by non-Council-members won't have labels to begin with (which I think you imply in point 2, but I wanted to make it clear).

Raff

On Mon, Dec 14, 2015 at 11:50 AM, Martin Holmes wrote:

...

This all makes sense to me. Perhaps the missing part right now is a clear statement of who is supposed to apply and verify these labels, at what stage. I would suggest:

1. When a Council member creates a ticket, they should do their best to apply all the correct labels.

2. When a ticket is created by a non-Council-member, any Council member who notices and has the time should go and check or assign the labelling.

3. When the Chair is triaging tickets before meetings, he/she should check and correct the labels for any tickets which have not yet been assigned.

As I was typing this I had a deja-vu sense that I've typed something very similar before, so perhaps we already discussed this at the FtF or in a telco?

Cheers, Martin

I think it would be useful to maintain the "migrated" label for a while longer. It doesn't cost anything - it's explicit and helpful. Should change "component" name as it's obviously confusing. The 4 main categories are the key thing. --elli On Mon, Dec 14, 2015 at 10:30 AM, Lou Burnard wrote:

On 14/12/15 13:30, James Cummings wrote:

...

On 14/12/15 13:07, Raffaele Viglianti wrote:

...

That is what we meant. What would be a good short label for this?

What about Component: TEI Guidelines vs Component: TEI Schema?

Except that any issue affecting the "TEI schema" (whatever that is) ought ipso facto to be affecting the TEI Guidelines prose (tho admittedly not necessarily vice versa)! When we e.g. add a new element, which is that? Or is it both i.e. two issues? I can see the advantage of distinguishing issues that relate purely to P5 from those that relate to (say) bugs in Roma, but I don't see the advantage of distinguishing aspects of P5.

...

...

Isn't that handled by having the different repositories?

Only the stylesheets, but not other "tools" like Jenkins and Roma. I'd still keep a label for Stylesheets as a signifier that the issue should be moved.

Agreed that this is useful.

...

...

Then I'd say something just like the name of the repository it should be moved to.

Oh, and there is a Roma repository (and maybe there should be a jenkins one?)

Agree with Jas here.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived