Project labels

[keikoro]

@tburrows13 continuing from here, I'm currently going through the labels we use to tag issues, wanting to clean them up.

I've already added several missing descriptions and would suggest we delete the (outdated, incomplete) Label-Wiki page, because I feel the label descriptions are sufficient. Do you agree?

In a next step, I'd like to see how we can consolidate labels, which (near) duplicates ought to be deleted and would also like to group them in a better or more obvious way colour-wise. Maybe you could also let me know which ones you use particularly often – or rarely/never.

[keikoro]

Deleted label optimization, Do we need this? Duplicate of 'enhancement'? after retagging sole issue with enhancement.

Suggesting consolidation of:

• github, Related to GitHub integrations/apps (3 closed)
• appveyor, no description (2 closed issues)

into new label integrations.
See the updated version of this suggestion down-thread.

[keikoro]

suggesting consolidation of:

• feature-change, Breaking change to the API. Do not merge without proper approval (4 open, 6 closed)
• breaking, Must be fully documented in a dedicated section in the changelog (1 open, 2 closed)

into breaking-change ... unless there's a good reason these are 2 separate things, in which case the descriptions need adapting to make the difference clearer.

[keikoro]

Deleted label cleanup, Duplicate of ‘refactor’? since there were no issues associated with it.

[keikoro]

I introduced the label 3rd-party (29 open, 43 closed) a long time ago, to quickly mark issues whose main focus is (probably) not moviepy, but another library that the project depends on.

We now also have more specific labels ffmpeg (1 open, 8 closed) imagemagick (4 open, 4 closed), and pygame (1 open, 1 closed).

I think it's ok to keep all of them, even if not all issues with the more specific tags are equally labelled 3rd-party. I'd also not think it necessary to strictly label everything with two tags. I.e. I don't find it problematic if there's a bit of "overlap" or redundancy as the one is a very "coarse" tag and the others are more specific flags.

[keikoro]

I suggest we delete python2 and python3 as each is used on only one issue, and the README states moviepy works with Python 3.6+.

Retracting this suggestion. See next comment.

[keikoro]

A label I was going to suggest we delete, compatibility, Duplicate of '3rd-party'? Or even at all necessary? (4 closed), seems to be about something else, namely Python 2/3 compatibility.

Now, we could delete it altogether along with the specific Python tags. However, I'd actually suggest we keep them for historic reasons, and also rename all of them to python-version (or similar). We could then continue to use this tag for any issues relating to (future) Python version upgrades.

As there's so few issues all in all, I really don't mind going in and retagging them.

[keikoro]

DONE.

A label I was going to suggest we delete, compatibility, Duplicate of '3rd-party'? Or even at all necessary? (4 closed), seems to be about something else, namely Python 2/3 compatibility.

Now, we could delete it altogether along with the specific Python tags. However, I'd actually suggest we keep them for historic reasons, and also rename all of them to python-version (or similar). We could then continue to use this tag for any issues relating to (future) Python version upgrades.

As there's so few issues all in all, I really don't mind going in and retagging them.

[keikoro]

Re: the suggestion I made for a new label integrations above:

it might actually make sense to use a more general label like tooling and broaden its scope from the two already mentioned, github (3 closed) and appveyor (2 closed) to also encompass issues currently tagged travis (3 closed) and docker (4 closed).

Addendum:
While the first 3 are related to the administration of the project/repo, the third is about tooling on the user level, and I can see the benefit of keeping the explicit Docker label (however, I wouldn't see anything wrong with Docker issues also getting tagged as tooling related ones.).

So I see three possibilities here:

1. merge the first three into project-tooling but keep the Docker tag and consider it something separate
2. merge the first three into tooling, keep the Docker tag but also tag the existing Docker issues with tooling and be fine with future Docker issues getting tagged as either or both
3. drop the Docker label and merge all four into tooling

[keikoro]

Suggesting merge of labels:

• awaiting-response, Waiting for author's reply or changes (3 open)
• needs more info, no description (5 closed)

I also suggest we replace all spaces in labels with dashes (for consistency, and because URLs with encoded spaces are ugly and not user-friendly).

[tburrows13]

I've already added several missing descriptions and would suggest we delete the (outdated, incomplete) Label-Wiki page, because I feel the label descriptions are sufficient. Do you agree?

Good idea - I've now deleted it. (I think maybe label descriptions weren't a thing when I created it?)

suggesting consolidation of:

• feature-change, Breaking change to the API. Do not merge without proper approval (4 open, 6 closed)
• breaking, Must be fully documented in a dedicated section in the changelog (1 open, 2 closed)

into breaking-change ... unless there's a good reason these are 2 separate things, in which case the descriptions need adapting to make the difference clearer.

Sounds good

Re: the suggestion I made for a new label integrations above:

it might actually make sense to use a more general label like tooling and broaden its scope from the two already mentioned, github (3 closed) and appveyor (2 closed) to also encompass issues currently tagged travis (3 closed) and docker (4 closed).

Addendum:
While the first 3 are related to the administration of the project/repo, the third is about tooling on the user level, and I can see the benefit of keeping the explicit Docker label (however, I wouldn't see anything wrong with Docker issues also getting tagged as tooling related ones.).

So I see three possibilities here:

1. merge the first three into project-tooling but keep the Docker tag and consider it something separate
2. merge the first three into tooling, keep the Docker tag but also tag the existing Docker issues with tooling and be fine with future Docker issues getting tagged as either or both
3. drop the Docker label and merge all four into tooling

I quite like keeping Docker separate (so either option 1 or 2). We also have the tests tag which is currently used for both changing the test suite and also the config control files relating to them. Perhaps this should be changed so that the config files are only project-tooling?.

I'm also trying to move away from Travis and Appveyor in favour of pure GitHub actions. We now have the test suite for Python 3.6, 3.7 and 3.8 running on linux with GH Actions, so Travis as actually no longer needed. I think I'll leave it there until it starts causing issues though. The windows GH Actions tests are there but they don't work yet, so Appveyor is still necessary.

[keikoro]

Good idea - I've now deleted it. (I think maybe label descriptions weren't a thing when I created it?)

I think you're quite right!

I quite like keeping Docker separate (so either option 1 or 2).

Yeah, I'd have also said option 1 or 2.

We also have the tests tag which is currently used for both changing the test suite and also the config control files relating to them. Perhaps this should be changed so that the config files are only project-tooling?.

I haven't looked through all of the rest yet, but I'm certain there are some more that could use cleaning up, or rethinking(/relabelling) or doing away with.

I'm also trying to move away from Travis and Appveyor (snip)

For now I'm concentrating on the labels only ^^ would suggest we discuss details regarding specific tools or workflows in separate issues.

I can still work on this a little today, will then pick up again tomorrow.

Also, btw. idk how (in)active Gitter is these days, or if it there's some other (newer, better, more popular) tool suitable for discussing things a little more (broadly) or across different issues, but I'll also happily check in with Gitter regularly again while working on stuff.

[keikoro]

Re spaces vs. dashes in labels:
I tried to research this just now but I'm not sure if GitHub differentiates between labels with spaces and ones with dashes in search results and such, e.g. if they'll return both when people search only for the former.

They wrote about beginner-focused labels on their blog, but didn't include a list of tags. Looking through the good-first-issue topic, which surfaces these, I only saw issues using the label with spaces. (Topics are something different, and can't have spaces, so we can't surmise from that page or its URL.)

So, just to be on the safe side, I'll keep the spaces in good first issue for now, but will replace them everywhere else.

[keikoro]

Deleted labels:

• resolved (1 closed issue)
• feature-removal (0 issues)

Renamed labels (and added/updates description, where necessary):

• documentation-needed (was needs documentation)
• invalid--duplicate (was duplicate)
• review-needed (was needs-review)
• breaking-change (was breaking)

Some of these I renamed so they'll show up before/after another label they are related to, seeing as the labels are sorted alphabetically. I think there's room for improvement in that regard for some other labels as well.

(Was thinking that "clustering" e.g. the ones for problem/usage areas that way might also be helpful, i.e. text, audio etc. Just needs a shared "prefix", sth. like topic-- or functionality-- or feature-- or similar.)

[keikoro]

I'm not sure if the mergable, Awaiting final merge approval tag is one we need to keep, or maybe I'm misunderstanding its purpose.

There are only 2 issues tagged with it, and I feel like it was used like what I understood review-needed meant, i.e. "I need/want another pair of eyes on this before we can proceed with". Or is review-needed more for any submitted PRs which no-one has looked at yet, and mergable more like a v2.0 of that, or the between-maintainers equivalent?

@tburrows13, could you shed some light?

[tburrows13]

I'd say that mergeable is not the same as review-needed.

Or is review-needed more for any submitted PRs which no-one has looked at yet, and mergable more like a v2.0 of that

Yes basically. However I don't think mergeable is needed at all. LGTM should probably cover that case, otherwise it should be merged :)

[keikoro]

Also uhm, I can see I'm already confusing myself here, lol. The rename of breaking-change above seems unnecessary given I meant to get rid of the breaking label anyway in favour of the feature-change one...

So, done now:

suggesting consolidation of:
* feature-change, Breaking change to the API. Do not merge without proper approval (4 open, 6 closed)
* breaking, Must be fully documented in a dedicated section in the changelog (1 open, 2 closed)

into breaking-change ... unless there's a good reason these are 2 separate things, in which case the descriptions need adapting to make the difference clearer.

[keikoro]

@tburrows13 Thanks! I'll remove mergable in this case and retag the 1 remaining issue with LGTM. Though I'm wondering if there's a simpler, more readable word for people not familiar with the acronym (not wanting to waste all description space with spelling it out). Will try to think of something.

Similarly, I'm unclear on the usage of needs-updating (1 open issue), and was wondering if it's similar to how WIP (2 closed) was previously used? I.e. in a "I'm on this, but this still needs work" sense? Wondering if we can consolidate these two, too.

Also, am I understanding new-behaviour, A change that affects the output/result (1 usage so far), correctly in that it was intended for issues/PRs that (suggest to) repurpose existing functionality? E.g. reuse an existing class or method name to do something else with it?

[keikoro]

I'm also wondering if the suggestion label (5 open, 2 closed) is perhaps a bit redundant (in some cases, one of the other labels might be sufficient) or if it could be renamed to something that would make sense to use for more issues. Will take a closer look and try to think of something.

[tburrows13]

I'd say needs-updating could be merged into awaiting-response. WIP is something that I'd expect the PR author to add themselves (but I don't think non-maintainers can edit labels anyway, so it should perhaps be removed entirely). Github has a 'draft' feature for PRs that does this better anyway.

new-behaviour should probably just be merged into breaking.

suggestion could be merged into feature-request?

[keikoro]

I'd say needs-updating could be merged into awaiting-response.

Done.

WIP is something that I'd expect the PR author to add themselves (but I don't think non-maintainers can edit labels anyway, so it should perhaps be removed entirely).

Yeah, AFAIK manual adding of labels doesn't work for regular users (the auto-labelling when opening new issues being a separate thing). Because of that, I thought it was meant to be used internally, by maintainers.

Github has a 'draft' feature for PRs that does this better anyway.

Oh, I didn't know about this. Will look into this.

new-behaviour should probably just be merged into breaking.

Done.

suggestion could be merged into feature-request?

There's the odd issue which doesn't fit that, like the one where a logo design was suggested, but I guess for the majority, your suggestion would work. Will think of sth. for the rest.

[keikoro]

Ok, apart from the suggestion label and the "topic" labels – video, audio, text etc. – for which I'd still like to find a shared prefix, this is pretty much done. Currently, the latter are only connected via a shared colour, which is "nice" but not helpful/obvious to everyone (never a good idea to rely on visuals only).

I still did some more minor renames of some labels yday, mostly to "group" them (closer) together (alphabetical sorting), and also tried to make the colour scheme make more sense.

The main thoughts behind the tweaked colours were: "group" related labels (use same colour or different shades of same colour), use different strong/signal colours for "important" or often-used labels (and remove such colours from lesser used or less important labels), try to find an overall "balance" of colours. I always wanted the "topic" labels to be blue, and tried to get more blues (& purples) in now for accessibility reasons but with the no. of labels we have, it's impossible to avoid colours which are less ideal in that regard (reds, greens) + keeping colour-shift/blue light filters in mind, a wider spectrum makes sense for everyone who can see all colours.

Btw., I also added a temp. label for Hacktoberfest: hacktoberfest-accepted – needed for OK'd contributions which won't get merged right away, so they count towards ppl's quota.

[keikoro]

While going through/tagging old issues, I've been encountering several asking about or reporting problems due to (lack of) async, multi-threading etc.

So far, I've used the performance label as a catch-all for all of these – along with the obvious "xy is taking forever, z slows down to a crawl when doing abc" ones – but I'm not sure if perhaps there's a better term for the former.

[tburrows13]

Using ‘performance’ seems fine to me for that

[keikoro]

Also got rid of the suggestion label now – folded it mostly into feature-request or enhancement (or whatever else was more appropriate).

[keikoro]

One other thing I've come across multiple times now, for which I found the existing labels insufficient (or even somewhat misleading), are issues mentioning specific platforms or environments.

I'd count questions about specific OS (e.g. "Can I make moviepy run on Android?") as well as bug reports which seem to have to do more with a particular env/OS/... a program is run on than underlying functionality being buggy in general among those. E.g. issues mentioning Windows-specific errors, or conda/anaconda, problems occurring within Docker containers might fit the label as well, and I'd also put anything to do with built executables in this category. Perhaps the odd problem occurring withing certain IDEs could be covered as well.

I just don't know which term would be preferable (broadest but still accurate) to use here. Environment?

Along similar lines, I've realised I'm sometimes a bit unclear on how I should label certain issues, particularly ones mentioning images, and might have muddled labelling them as a consequence (video vs. images label). Though maybe that's kinda unavoidable? I guess there's a bit of a conflict between labelling issues for people looking for existing issues similar to their own problems (use of same classes, methods), and for linking together issues which involve the same file types (because problems might originate from how certain file types "work").

[tburrows13]

environment seems like a good term there.

Did there used to be a discussion label? I think it would be a good fit for #1339?

[keikoro]

Hm, I don't remember there to be a discussion label.

Is this meant for new issues where we want to bring up and discuss stuff or also for (any) issues which evolve into longer discussions? I guess I'm asking if this is a direct replacement for the now deleted suggestion, or more than that, and if there's a more precise term we could use.

[keikoro]

It's probably meant mostly as a "signal" or "activator" for heavy users/maintainers, a "hey, look at this" or "you might wanna get involved here" (and could be used alongside refactor or feature or similar)? And meant for issues where more detailed thoughts about how the project or parts of it could be made better are laid out?

[keikoro]

(I'm thinking the biz equivalent would be sth. like product development, or product mgmt...?!)

[keikoro]

architecture? design? + an "activating" term. Maybe sth. like design-decisions or... decision-making or process or similar in combo with sth. else, hmm.

[keikoro]

I've created design-decisions for now, we can always rename it to sth. different if it turns out too narrow/broad/unclear.

[keikoro]

Just added a new label fx for effects applied via clip.fx(), i.e. advanced clip manipulations.

[keikoro]

I've been finding myself using the more specific labels for third-party libraries/dependencies recently when tagging new issues rather than the generic 3rd-party label I created in the past, so I was wondering if it would make sense to only use the generic label for dependencies which don't have their own label and/or additional libs (e.g. ones requested in feature requests) moving forward.

I'm also thinking it would make sense to rename the individual labels for dependencies so they share the same prefix, e.g. lib: ffmpeg or lib-ffmpeg or similar. That way they are easier to locate in the labels list or when labelling issues (i.e. no time wasted looking for a label that doesn't exist). Any preferences for a prefix – lib vs. dep or something else completely?

Relatedly, we also have a label dependencies, which, so far, seems to have only been used for PRs. ATM, this serves more or less the same purpose as the 3rd-party label, making one of them redundant, I feel? However, if we start using the latter as suggested above, it would make sense to keep both. Btw. I'm very much open to suggestions for a better name for the 3rd-party label.

[keikoro]

I've prefixed the individual dependency labels with lib- for now, e.g. lib-ffmpeg. I'm also in the process of adding those and removing the generic 3rd-party one on open issues this is applicable to.

I might rename the 3rd-party one to lib-3rd-party for the time being so it gets grouped with the rest of them.