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

Prepare "how to contribute" guide (Wiki) #302

Open
7 of 12 tasks
taiya opened this issue May 7, 2020 · 7 comments
Open
7 of 12 tasks

Prepare "how to contribute" guide (Wiki) #302

taiya opened this issue May 7, 2020 · 7 comments
Assignees
Labels
WIP Work In Progress

Comments

@taiya
Copy link
Collaborator

taiya commented May 7, 2020

This will be needed for the three upcoming Google Summer of Code projects.
Let me know if you think I am missing something?

  • Attribution of copyright (CLA)
  • fork process
  • setup pythonpath
  • pull request process
  • Github Actions and TravisCI
  • google style linting
  • how to run tests
  • three level contributions: {core, project, submodule}
  • code formatting – yapf
  • code coverage
  • how to write tests for your contributions
  • Running locally vs. on ai-platform
@jackd
Copy link
Contributor

jackd commented May 9, 2020

Not specifically related to GSoC, but as someone who's keen to contribute whenever I find time:

  • is there a formal/informal RFC process for medium sized/larger works?
  • what is the expectation in terms of maintenance after a PR is accepted?
  • format specifications (yapf? command line args?)

@taiya
Copy link
Collaborator Author

taiya commented May 9, 2020

  • Yes, for RFC communication happens via this github issues channel
  • Depends on what above I call "level of contribution"
    • core: you can help, but we are fully responsible
    • project: depending on how important it is we might maintain it, according to how useful it is. (e.g. PointNet is ubiquitous, so the fact that its training pipeline is well oiled is important, other contributions might be less fundamental)
    • submodules: currently there are zero requirements, but I expect a dry-run coverage test will be asked at last, and if that test fails for too long – author's repo not maintained – we can drop the dependency. We have not setup this yet though.
  • We are using Google standard python format. I have not setup yapf-like automated systems yet, but would be great to add that in (will likely happen soon'ish)

@julienvalentin
Copy link
Contributor

this looks good to me Andrea

@taiya taiya added the WIP Work In Progress label May 23, 2020
@taiya
Copy link
Collaborator Author

taiya commented May 23, 2020

@taiya
Copy link
Collaborator Author

taiya commented May 23, 2020

@sofienbouaziz julien removed TravisCI, but the Build workflow does not check for coverage. You might want to add it back, and add the corresponding docs to this page?

@taiya taiya pinned this issue May 23, 2020
@Molkree
Copy link
Contributor

Molkree commented Jun 5, 2020

Hi, @ataiya!
You might want to add the section about notebooks too. TensorFlow Docs team has notebook formatter. Just a link to existing Docs guidelines and a mention that failing formatting check will prevent PR from merging (just like linting and tests) would probably be enough.
I can format existing notebooks and add formatter test to the workflow (in fact I've already done half of it here so if you are interested, let me know!)

@taiya
Copy link
Collaborator Author

taiya commented Jun 5, 2020

That's an interesting idea, but I let @julienvalentin comment here.
I do not use notebooks, nor will I ever :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WIP Work In Progress
Projects
None yet
Development

No branches or pull requests

5 participants