Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: add labels documentation. #1582

Merged
merged 1 commit into from May 16, 2017
Merged

Conversation

ldez
Copy link
Member

@ldez ldez commented May 10, 2017

Description

Add an explanation for each label we use.

https://mensuel.framapad.org/p/EYZcWzVbgO

Copy link
Contributor

@timoreimann timoreimann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why we wouldn't use a markdown file?

This would have the advantage that we could better structure the document and use tables to better display things like issue-only/PR-only, etc.

area/websocket:: WebSocket related.
area/webui:: Web UI related.
area/infrastructure:: related to CI or Traefik building scripts.
area/documentation:: regards improving/adding documentation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also opt for area/middleware.

area/documentation:: regards improving/adding documentation

priority/P0:: needs hot fix. (only for issue)
priority/P1:: fixed in next release. (only for issue)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed sounds like this is only meant for bugs. Should we say shipping instead?

(Same for P2.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or need to be fixed in ...

priority/P0:: needs hot fix. (only for issue)
priority/P1:: fixed in next release. (only for issue)
priority/P2:: fixed in the future. (only for issue)
priority/P3:: maybe. (only for issue)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/maybe/backlog/?

contributor/waiting-for-corrections:: (only for PR) we need the contributor to take actions in order to move forward with a PR
contributor/needs-rebase:: (only for PR) use it only when there is some conflicts (and an automatic rebase is not possible) [bot, humans]

duplicate:: it's a duplicate issue/PR.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move duplicate next to declined.

I also suggest to prefix it with with resolution/.


duplicate:: it's a duplicate issue/PR.

enhancement:: a new or improved feature
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we prefix enhancement, question, and proposal with kind/ (similar to how Docker and k8s do it)?

@ldez
Copy link
Member Author

ldez commented May 11, 2017

Asciidoc have better render for everything: table, list, image, video, ...

@emilevauge
Copy link
Member

@ldez

Asciidoc have better render for everything: table, list, image, video, ...

We all agree on this. But I think that contributors may be unwilling to use/learn Asciidoc instead of the simple/widespread Markdown. I think that the documentation should be the easiest possible to modify by contributors (even if Asciidoc is better and not that complex, Markdown is simpler).


platform/windows:: Windows related.

area/provider/boltdb:: Boltd DB related.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also should have a area/provider one (something that would affect all the providers for example)

@ldez
Copy link
Member Author

ldez commented May 11, 2017

You can use Markdown syntax in a Asciidoc document.

@emilevauge
Copy link
Member

emilevauge commented May 11, 2017

@ldez I don't think we want/need to change the documentation format right now. And we really don't want to have 2 formats at the same time.

Copy link
Contributor

@timoreimann timoreimann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kind/quality is still missing.

@timoreimann
Copy link
Contributor

Right now, the bug/* labels are the only ones that stand out. I think we should also group them under the kind/ namespace, e.g., kind/bug/possible, kind/bug/confirmed, and kind/bug/fix. This would be consistent IMO.

@ldez
Copy link
Member Author

ldez commented May 12, 2017

kind/quality it's still in discus for me.

Copy link
Contributor

@timoreimann timoreimann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. 👍

@ldez ldez force-pushed the doc/maintainer-labels branch 2 times, most recently from f397749 to 651deef Compare May 12, 2017 13:15
Copy link
Member

@emilevauge emilevauge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ldez !
LGTM

Copy link
Contributor

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🦁
Needs a rebase 👼

@ldez ldez merged commit 40c94d8 into traefik:master May 16, 2017
@ldez ldez deleted the doc/maintainer-labels branch May 16, 2017 15:59
@ldez ldez added this to the 1.4 milestone May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/documentation kind/enhancement a new or improved feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants