Re: [tei-council] Reorganizing labels on GitHub

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 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