Skip to content
This repository has been archived by the owner on Dec 22, 2021. It is now read-only.

Expand the developer guide #302

Open
leouieda opened this issue Jul 21, 2016 · 0 comments
Open

Expand the developer guide #302

leouieda opened this issue Jul 21, 2016 · 0 comments
Labels
Milestone

Comments

@leouieda
Copy link
Member

The developer docs have been a great starter for how to contribute to the project. However, it's starting to show its age and is not as detailed and comprehensive as it could be.

I'm proposing a restructure of the docs as follows:

  1. Include "Reporting bugs and requesting features" (aka how to open issues on Github) and "Improving the documentation" into the developer guide. These are all non-code contributions but are just as needed (if not more).
  2. Separate the docs on different pages (this will go along with Separate the developer docs into different files #220) but the separation should be made by barrier-to-entry level (from smallest to largest) : giving feedback; contributing text/docs; contributing code; git+github workflow; project administration (making releases and packaging).
  3. Rename "Developer Guide" to "Contributing" or "Getting involved". "Developer" might put newcomers off.

Each page would have the following content:

Giving feedback

  1. What are the options for this: mailing list and issues (preferred)
  2. How should you behave on our forums (a code of conduct)
  3. What to expect from us (polite/friendly replies but we won't implement something just because you asked)
  4. Where is the mailing list and what you need to subscribe
  5. What is an issue and how make one.

Improving the documentation

  1. The docs are always evolving and need your help
  2. How the documentation is generated and where does it live (source and built pages)
  3. Where you should go to learn how to use sphinx
  4. How to build the docs locally
  5. The format that we use for docstrings etc
  6. Contributing something to the docs (point to git workflow)

Contributing code

  1. How to find things to work on (issues and low-hanging fruit)
  2. Tell us what you plan and ask if we'd accept this contributing (create/post issue or write to mailing list)
  3. What we expect from contributed code (readable, tested, documented)
  4. What you can expect from us during the code review (we'll be polite and helpful, review thoroughly, etc)
  5. Where the code lives and how it's structured
  6. Quickly download a copy and build + test it locally
  7. How to manage and submit your contributing (point to git workflow)
  8. How to test your code
  9. How to document your code (point to improving docs section)
  10. How profile and improve your code

Git workflow

(Thanks to @PiotrKurnik for pointing out that we need this a lot)

  1. How to get a fork
  2. Clone your fork locally
  3. Work on branches
  4. Submit a PR (earlier rather than later) and the review
  5. Continuous integration checks
  6. Keeping your fork updated (fetching from upstream master)

Project management

(This is what is currently only in my head. I'd like to put this out there in case someone else wants to help or take over the work.)

  1. How to package the project (what's in setup.py)
  2. Checking your package
  3. Tag the release and mark it on Github
  4. Update the website
  5. Uploading to PyPI
  6. Creating conda packages (this is something I have to figure out as well but conda-forge seems like the way to go)

Pinging all @fatiando/contributors. Is anything missing? Is the order OK? What are your thoughts on this?

@leouieda leouieda added the docs label Jul 21, 2016
@leouieda leouieda added this to the 0.6 milestone Jul 21, 2016
@leouieda leouieda self-assigned this Jul 21, 2016
@leouieda leouieda removed their assignment Sep 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant