sql_datastore's Introduction

Data Together

Data Together empowers people to create a decentralized civic layer for the web, leveraging community, trust, and shared interest to steward data they care about.

Find out about who we are, what we do, and how to get involved at https://datatogether.org/)!

Organizational structure

We maintain pretty light governance but commit to an annual in-person meeting and quarterly calls:

Quarterly Calls

Quarterly calls are held four times annually, for everyone, but especially Data Together partners to sync up on ongoing projects, what is going on in their organizations, and more.

📅 Once per quarter
▶️ Call Playlist: youtube.com/playlist?list=PLtsP3g9LafVul1gCctMYGm9sz5FUWr5bu

Working Openly

We have developed guidelines for working as an open project, these are all contained in this repo:

License

Data Together Documentation Materials are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

sql_datastore's People

Contributors

Stargazers

Watchers

sql_datastore's Issues

Add README and Templates

Make sure this repo has the following files:

Readme README.md
- Repo Badges for: Github Project, Slack, License
- 1-3 sentence description of repository contents
- Getting Involved section
- Development section
License -- LICENSE
Contributing Guidelines (minimal and pointing to org-wide) .github/CONTRIBUTING.md
Issue Template -- .github/ISSUE_TEMPLATE.md
GitHub Description from 1-3 sentence readme blurb

This issue forms part of a project-wide meta-issue

Generate github issues from TODOs in code

From convo in #2 and @b5:

All TODO's need to be addressed at some point, if it's "urgent" I tend to address it then & there. My main reasoning for using TODO is to manage technical debt by pointing out areas that need work.
By that logic all TODO's represent potential issues, all roughly in the realm of code quality. TODO's who's comments include phrases like "awful mess" or "remove this ugliness" are of a higher priority.
See also my comment on datatogether/archive#16

ok to archive this repo?

valid keys

Does SQL generally have any restrictions on what characters can be used as a 'key' here? IPFS likes to use raw hashes as the keys, i'm not sure how well that would work here. Any ideas @b5 ?

Recommend Projects