Skip to content

Commit

Permalink
[pre-commit.ci] auto fixes from pre-commit.com hooks
Browse files Browse the repository at this point in the history
for more information, see https://pre-commit.ci
  • Loading branch information
pre-commit-ci[bot] committed Dec 16, 2024
1 parent e910903 commit 4e819b3
Show file tree
Hide file tree
Showing 3 changed files with 8 additions and 8 deletions.
4 changes: 2 additions & 2 deletions docs/folders-and-naming.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,8 +18,8 @@ since there are many things which can be named, here provide general guidelines.
- **Theme based naming.** As much as possible, ensure names are informative and match with topic/theme. For example, in the data folder, one can have directory for ```admin-boundaries```

## Adding Data to Project Sharepoint
We recognize that this approach may create some duplication and additional effort. However, wherever possible (if datasets arent to large), we require that datasets (both raw and derived) be uploaded to the project’s SharePoint. This enables other Bank staff, who are often our clients on the project, to access the data as needed. In summary, you will maintain copies of the data in the data folder on your local machine for your analysis. As outlined in the [Git workflows](/docs/git-workflows.md), this data will not be uploaded to GitHub and will remain locally stored.
We recognize that this approach may create some duplication and additional effort. However, wherever possible (if datasets arent to large), we require that datasets (both raw and derived) be uploaded to the project’s SharePoint. This enables other Bank staff, who are often our clients on the project, to access the data as needed. In summary, you will maintain copies of the data in the data folder on your local machine for your analysis. As outlined in the [Git workflows](/docs/git-workflows.md), this data will not be uploaded to GitHub and will remain locally stored.

## Programming Environments
- **Python virtual environments.** We recommend using ```.venv``` for virtual environments. This allows for automatic detection by tools and editors like VS Code, simplifies setup, and keeps the folder hidden in most operating systems, reducing clutter. It also promotes consistency across projects, making it easier for others to understand and navigate your setup. because this keeps the folder tree clean among other advantages.
- **Environment file for secrets and credentials**. In the project folder, you will find a file ```.env.example```, rename that file to ```.env```. This is what you will to keep API keys and other secrets. Again, refer to [this part](https://worldbank.github.io/template/README.html) of the documentation for details.
- **Environment file for secrets and credentials**. In the project folder, you will find a file ```.env.example```, rename that file to ```.env```. This is what you will to keep API keys and other secrets. Again, refer to [this part](https://worldbank.github.io/template/README.html) of the documentation for details.
4 changes: 2 additions & 2 deletions docs/git-workflows.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,12 @@ This section provides essential guidelines for using Git and GitHub effectively,
## Branch Names and Other General Practices
- **Branch names**. After joining the project and cloning the repository, create a concise, descriptive branch name for your work and ensure you switch to that branch before beginning any work on your machine.
- **Update branches**. Avoid creating new update branches; instead, push your changes and resolve any conflicts directly. For instance, if bots in the repository modify your code (e.g., adjusting indentations), simply pull these changes before pushing your own updates.
- **Pull requests (PR)**. When you believe your changes are final, create a pull request and assign the project lead as the reviewer.
- **Pull requests (PR)**. When you believe your changes are final, create a pull request and assign the project lead as the reviewer.

## Folders and Files to Ignore
As all data science repos in the Data Lab use this template, the project repo will come with ```.ignore``` file prepopulated with most files and folders which need to be ignored. However, once you join the project and create your own branch. You will have to make sure that the following folders are being ignored.

- Data folder
- Virtual environments (```.venv```)
- Environment (```.env```)
Feel free to add any other files (e.g., system files specific to your OS) to the ```.gitignore```
Feel free to add any other files (e.g., system files specific to your OS) to the ```.gitignore```
8 changes: 4 additions & 4 deletions docs/notebooks-workflows.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,12 @@
This section provides guidelines for structuring analytical notebooks to enhance readability. The guidelines include recommendations for hiding code cells to maintain a clean appearance in Jupyter Book, incorporating references where relevant, and organizing content logically to ensure clarity for readers.

## General Notes
- **Notebook subfolder**.
- **Notebook subfolder**.
As noted in the [Naming and Folder Setup section](/docs/folders-and-naming.md), ensure you create a subfolder within the project’s notebooks folder. This subfolder should be named based on the theme of your assignment, serving as a dedicated space for your notebooks. This practice is especially important, as most Data Lab projects cover multiple topics and involve collaboration among several team members.
- **Notebook Structure**. In all Data Lab projects, we adhere to [this analytics structure](https://github.com/worldbank/sudan-poverty-monitoring/blob/main/docs/2-analytics.md). Ensure that your notebook follows this same structure.
- **Adding a README.md** If you look at the recommended notebok structure, it has sections on data used and methodology. In some cases, this information may better presented in a separate markdown file. You can add a ```README.md``` within your notebooks subfolder. This will provide detailed information about data sources and methodology.
- **Previewing Jupyter Book** As you are aware, the ```_toc.yml``` controls whats rendered in the Jupyter Book. Please edit the file accordinly to add your notebooks and other ```markdown``` files as needed. This will allow you to build the book locally using ```make build``` command and preview and check if your notebooks are rendering as expected.

- **Adding a README.md** If you look at the recommended notebok structure, it has sections on data used and methodology. In some cases, this information may better presented in a separate markdown file. You can add a ```README.md``` within your notebooks subfolder. This will provide detailed information about data sources and methodology.
- **Previewing Jupyter Book** As you are aware, the ```_toc.yml``` controls whats rendered in the Jupyter Book. Please edit the file accordinly to add your notebooks and other ```markdown``` files as needed. This will allow you to build the book locally using ```make build``` command and preview and check if your notebooks are rendering as expected.
- **Removing/hiding cell blocks** All notebooks will be rendered in Jupyter Book. To enhance readability, ensure code cells are hidden or removed using cell tags. In some cases, you may use the hide-input cell tag.


Expand Down

0 comments on commit 4e819b3

Please sign in to comment.