54 mantainer guide by ManuelAlvarezC · Pull Request #71 · CoronaWhy/task-geo

ManuelAlvarezC · 2020-04-23T11:15:15Z

Description

Add a first version of the Maintainer Guide
Fixed issues that arise warnings on docs generation.
Linting docstrings a little.

Related to #54, but doesn't fix all the issues.

Checklist:

Moved task_geo.data_sources.covid.fr_covidata -> task_geo.data_sources.covid.fr_covid and split in multiple files Moved task_geo.data_sources.covid.spain -> task_geo.data_sources.covid.es_covid Fixing issues with docstrings formatting on different modules Add example notebooks to the documentation index

wwymak

Mostly nitpicks, otherwise looks fine. However, you might want to call maintainer_guide CONTRIBUTING instead (that's what a lot of the bigger open source projects do).

Actually, might be nice to also add a guideline on branching etc. (e.g. only create branches, and if you fork, please don't use master branch for your changes... 😉 )

wwymak · 2020-04-23T13:46:15Z

docs/maintainer_guide.rst

+Maintainer Guide
+================
+
+This document purpose is to define and concrete the tasks related to maintaining the github repository


Suggested change

This document purpose is to define and concrete the tasks related to maintaining the github repository

This document's purpose is to define and concrete the tasks related to maintaining this github repository

(also not too sure 'concrete is the right word to use here 🤔 )

To "concrete" doesn't exist afaik. Maybe "to concretely define", or "to define and make concrete".

wwymak · 2020-04-23T13:46:48Z

docs/maintainer_guide.rst

+to have a detailed description of each of the task to serve as both:
+
+1. Reference for Mantainers of the repository
+2. Guide for users who may be interested in improve it's contribution workflow.


Suggested change

2. Guide for users who may be interested in improve it's contribution workflow.

2. Guide for users who may be interested in improving the contribution workflow.

wwymak · 2020-04-23T13:46:59Z

docs/maintainer_guide.rst

+This document purpose is to define and concrete the tasks related to maintaining the github repository
+to have a detailed description of each of the task to serve as both:
+
+1. Reference for Mantainers of the repository


Suggested change

1. Reference for Mantainers of the repository

1. Reference for maintainers of the repository

wwymak · 2020-04-23T15:28:38Z

task_geo/dataset_builders/nasa/nasa_connector.py

+
    """
    if parms is None:
        parms = list(PARAMETERS.keys())


maybe fix spelling on this parms too?

wwymak · 2020-04-23T15:29:41Z

task_geo/dataset_builders/nasa/nasa_connector.py

-    parms_str : string
+    Parameters:
+        lat(string)
+        lon(string)


hmm, is it just me but why do we want lat/lng as a str ? 👀

wwymak · 2020-04-23T15:35:19Z

task_geo/data_sources/covid/fr_covid/fr_covid_connector.py

+    """
+    urlData = requests.get(url).content
+
+    return pd.read_csv(io.StringIO(urlData.decode('utf-8')))


simpler if you just use pd.read_csv(url)... (and I've checked, it does work without having to specify anything else)

wwymak · 2020-04-23T15:37:19Z

docs/maintainer_guide.rst

+   everything is ok, we add the ``output-ok`` label and continue to the next step.
+
+4. **Peer review / Code review:** This is the final step, where we read the code and analyze it 
+looking for flaws, things that should be looked include:


Suggested change

looking for flaws, things that should be looked include:

for flaws. Things that should be considered include:

wwymak · 2020-04-23T15:38:50Z

docs/maintainer_guide.rst

+Pull requests
+-------------
+
+Pull Requests are open by collaborators who whish their work to be included in the repository.


Suggested change

Pull Requests are open by collaborators who whish their work to be included in the repository.

Pull Requests are opened by collaborators who wish their work to be included in the repository.

wwymak · 2020-04-23T15:41:10Z

docs/maintainer_guide.rst

+
+1. **Verification and design:** After receiving the feature request, we must make sure that the proposal:
+
+   a) Makes sense in the scope of this project and his motivations.


Suggested change

a) Makes sense in the scope of this project and his motivations.

a) Is within the scope of this project and its motivations.

wwymak · 2020-04-23T15:43:09Z

docs/maintainer_guide.rst

+Support issues came from users who tried to use our package but the the documentation ( or the
+lack of thereof) wasn't helpful enough to get the results they wanted.
+
+Usually this issues don't require developing code, just explaining the user how to use our package.


Suggested change

Usually this issues don't require developing code, just explaining the user how to use our package.

Usually to resolve these issues don't require developing code, just explaining to the user how to use our package.

hyberson

I'm not a GitHub user. I can't really review this.

ManuelAlvarezC added 3 commits April 23, 2020 12:06

Add maintainer guide

d2b5498

Merge branch 'master' into 54_mantainer_guide

58e8566

ManuelAlvarezC requested review from DanielRobertNicoud, hyberson and wwymak April 23, 2020 11:15

wwymak approved these changes Apr 23, 2020

View reviewed changes

hyberson reviewed Apr 23, 2020

View reviewed changes

	This document purpose is to define and concrete the tasks related to maintaining the github repository
	This document's purpose is to define and concrete the tasks related to maintaining this github repository

	2. Guide for users who may be interested in improve it's contribution workflow.
	2. Guide for users who may be interested in improving the contribution workflow.

	1. Reference for Mantainers of the repository
	1. Reference for maintainers of the repository

	looking for flaws, things that should be looked include:
	for flaws. Things that should be considered include:

	Pull Requests are open by collaborators who whish their work to be included in the repository.
	Pull Requests are opened by collaborators who wish their work to be included in the repository.


		1. Verification and design: After receiving the feature request, we must make sure that the proposal:

		a) Makes sense in the scope of this project and his motivations.

	a) Makes sense in the scope of this project and his motivations.
	a) Is within the scope of this project and its motivations.

	Usually this issues don't require developing code, just explaining the user how to use our package.
	Usually to resolve these issues don't require developing code, just explaining to the user how to use our package.

Conversation

ManuelAlvarezC commented Apr 23, 2020

Description

Checklist:

Uh oh!

wwymak left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyberson left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wwymak left a comment •

edited

Loading