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

Document all phases' high-level functions in app/phases/*/doc.go #614

Closed
luxas opened this issue Dec 25, 2017 · 7 comments
Closed

Document all phases' high-level functions in app/phases/*/doc.go #614

luxas opened this issue Dec 25, 2017 · 7 comments
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@luxas
Copy link
Member

luxas commented Dec 25, 2017

Right now this text is missing in most places, or out of date.
The counterproposal here would to NOT document the high-level function of the phase in the code at all, instead in other docs.
cc @fabriziopandini @xiangpengzhao WDYT?

@luxas luxas added this to the v1.10 milestone Dec 25, 2017
@luxas luxas added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. kind/documentation Categorizes issue or PR as related to documentation. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Dec 25, 2017
@xiangpengzhao
Copy link

From my perspective, it'd be good to document them in other docs which are user-faced. But if the docs in the code can be automatically generated to a user-faced doc, it'd be better to keep the docs in the code for it's easier to keep docs in code up-to-date.

@luxas
Copy link
Member Author

luxas commented Dec 26, 2017

if the docs in the code can be automatically generated to a user-faced doc

I'm not sure how easy/hard this is... @fabriziopandini ?

@fabriziopandini
Copy link
Member

fabriziopandini commented Dec 26, 2017

IMO high level description of phases should be done in user-facing documents like e.g. init workflow.

I don't think that we should create a direct connection between doc.go files and the above user facing docs. Instead we should use doc.go for documenting implementation details only for packages that need large amounts of introductory documentation as suggested by godoc guidelines.

One last consideration; if we can transform this issue in a checklist with detailed actions items it will be easier to get help from other contributors here

@luxas
Copy link
Member Author

luxas commented Dec 27, 2017

I don't think that we should create a direct connection between doc.go files and the above user facing docs. Instead we should use doc.go for documenting implementation details only for packages that need large amounts of introductory documentation as suggested by godoc guidelines.

👍

if we can transform this issue in a checklist with detailed actions items it will be easier to get help from other contributors here

Sounds good to me, @fabriziopandini can you post such a list with what you see as necessary advice here please?

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 1, 2018
@neolit123
Copy link
Member

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 1, 2018
@timothysc
Copy link
Member

Closing this issue in favor of the 1/2 dozen others around promoting phases and current ongoing efforts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

7 participants