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

[DRAFT] Early points for discussion #1

Open
9 tasks
vsoch opened this issue Jan 25, 2020 · 0 comments
Open
9 tasks

[DRAFT] Early points for discussion #1

vsoch opened this issue Jan 25, 2020 · 0 comments

Comments

@vsoch
Copy link
Contributor

vsoch commented Jan 25, 2020

This is a list of TODOs / discussion points that I don't want to forget :)

  • LICENSE I copied the sourcecred standard - using MIT and APACHE, and I'd want to talk about if/when SourceCred is an official entity (we could use on licenses) and update here.
  • Pypi metadata: We can put various classifications for everything from intended audience to license and programming languages / platforms supported. I chose the standard that I would expect, and I'd want to ask for feedback.
  • Typing: I've been hesitant to add native typing to most of my Python projects, because realistically most of the world isn't there yet (and we would lose a lot of users to require 3.8+) however as an intermediate we could use mypy. I won't add this off to bat, but it could be added after. I'm starting to see in the compat.js that we really should be checking types. Ohhh Python :)
  • Others to add to pypi: I can manage the package (I manage quite a few!) but I'd want to add any others that would want / warrant access to it. Pypi has recently been upping their security game (two factor auth and tokens, just a random note)
  • Testing: I figure it's easiest to start with GitHub Actions, since it's a native thing now. If there are other builds warranted (e.g., containers) then we can consider adding another platform to speed things up.
  • Containers: speaking of! If it's appropriate, we could provide a container with SourceCred python. As long as we are able to keep this relatively up to date, this seems like it would be useful for some kind of data scientist that quickly wants to grab the latest version for a project.
  • Any convention preferred for file headers (e.g., see this post) I'm doing a standard module docstring that references the licenses provided with the repository, and any small details that I see in the upstream language sourcecred/sourcecred.
  • I can use camel casing to mirror the upstream project, is that weird?
  • add proper logger / warnings
    Please consider this issue under development / draft - I will remove this statement when it's ready for discussion! I have a ton of work to do before that, and I also will be adding a lot more points, and likely even moving them into their own issues. This is an initial brain dump.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant