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

Add in a GENERAL_INFO.md document? #37

Open
6 tasks
jGaboardi opened this issue Dec 2, 2022 · 5 comments
Open
6 tasks

Add in a GENERAL_INFO.md document? #37

jGaboardi opened this issue Dec 2, 2022 · 5 comments
Assignees

Comments

@jGaboardi
Copy link
Member

jGaboardi commented Dec 2, 2022

We should maybe add some sort of file in the top level for general information, etc. like:

  • versioneer usage and set up
  • pre-commit set up
  • GHA and secrets information
  • how to set up gh-pages branch
  • links to Wikis and other repos for demos
  • setting up condaforge-feedstock and auto-merge (xref Automated merging for conda-forge feedstock #31)
  • other stuff – PLEASE ADD TO LIST!!!

Maybe a file like GENERAL_INFO.md, where we make it clear that the file should be deleted when setting up an actual repo.

@knaaptime
Copy link
Member

yeah, and it should probably replace https://pysal.org/docs/devs/ with the latest conventions (and maybe we leave this kinda developer documenting to here instead of the website so we dont get competing resources?)

@jGaboardi
Copy link
Member Author

yeah, and it should probably replace https://pysal.org/docs/devs/ with the latest conventions (and maybe we leave this kinda developer documenting to here instead of the website so we dont get competing resources?)

Seems like a reasonable idea.

@martinfleis
Copy link
Member

I would personally update https://pysal.org/docs/devs/ with such an info rather than creating another place for it.

@knaaptime
Copy link
Member

knaaptime commented Dec 2, 2022

Agree we should have a single source, but i'd rather re-canonize it here. To me, the website feels like a place for users more than developers, whereas the submodule contract is where it makes more sense to house the 'dev set up' instructions.

Right now both the submodule template and the website contain competing instructions, so i vote here rather than there. Tbh, i forget the website instructions even exist--but maybe thats just me. No worries if im outvoted

@martinfleis
Copy link
Member

I don't mind where is it, but agree that there should be only one source of truth. Could be here.

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

No branches or pull requests

3 participants