search

Pixelmatters / pixelmatters-github-labels

Enhance Github labelling system, in a Pixelmatters' way.
MIT License
1 stars 0 forks source link

Compatibility-based questions #1

Open tiagoqueiros opened 3 years ago

tiagoqueiros commented 3 years ago

Hello there, I have some questions regarding this proposal:

  1. When someone does a PR review to a colleague and mark the PR as "request changes", should the label be updated too? If so, would it be possible to have a mechanism that changes the PR status automatically?

  2. Regarding the In Internal QA status, should it be applied to any project? From past experiences, the QA process occurs after PR merging, mostly because of the deployment platform. For example, using Divio it isn't flexible enough to generate contextual environments based on PRs (not that I'm aware of, that is - I only been able to do so in Heroku-based projects).

  3. Using a dependency manager service (eg.: Dependabot), normally PRs are created with a label indicating that it is a dependency bump. For the proposed scenario, what label should it correspond to?

  4. Having in mind a mono-repo reality, we can have scenarios on it would be interesting to identify the correspondent module (eg.: front-end, back-email, emails). Is it possible to extend this labelling system to have in mind this scenario? If so, what nomenclature do you propose?

Thanks!

gil0mendes commented 3 years ago

I'll leave some suggestions and opinions about this topic.

  1. I'm the type of person that goes tired and overwhelmed with the number of tags in a project. Let us do some research to find a way to have some automation, as @tiagoqueiros mentioned?
  2. I have the same opinion as @tiagoqueiros. Not all of the projects have a feature to open temporary branches with the PR content. This should be adopted on a project basis after consideration. This In Internal QA can also lead to some state duplication between JIRA boards and the repository state. I see a point where state inconsistency and loss of a single source of truth about the state things.
  3. (@tiagoqueiros point 4) I would suggest adding a kind of tag with the type of work. This is typical stuff on the maybe open source projects, for example.
  4. The type tag can be redundant since we already adopted conventional commits on every project inside Pixelmatters. If it's to move along with this, automation should be considered to reduce manual redundancy.
tiagoqueiros commented 3 years ago

@rmartins90 having in mind the feedback left here, I can assume we can advance with point 2 on removing the In Internal QA label.

What do you think?

tiagoqueiros commented 3 years ago

@gil0mendes For the remaining points, I've found two actions that can automatically sync labels:

I understand that we can signal point 4 using conventional commits. It depends on how you use the "optional scope". Usually, I see it associated with an issue tracking system slug.

What do you think?

rmartins90 commented 3 years ago

Sorry for reaching here just now.

  1. I wasn't aware of the existence of that bot @tiagoqueiros, it makes total sense to include it absolutely. Please move on with the configuration of that and make a Pull Request updating documentation referring to that with all configurations needed;
  2. It Makes total sense. This package should be agnostic to those project details. Can you move on with a PR as well @tiagoqueiros?
  3. Completely agree;
  4. I believe that adding Dependabot support would be good but not sure about mono-repo. That should be added to a project repo accordingly.

Thanks for the great feedback guys.