Re: [tei-council] Reorganizing labels on GitHub

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