Build org schema

[jayvdb]

The 'org' is either a incorporated entity, or an unincorporated entity, depending on the type of org, and should only have properties related to that. So far we only have 'org' name.

A lot of the other apps have a concept of an org which is only a small facet of the 'org', based on their limited data and scope. e.g. GCI and GSOC and OpenHub and any attempt at modelling GitHub/GitLab directly or via IGitt.

• org -> projects (coala, coala-bears, etc)
• org -> programs (GCI, GSOC, newcomer-onboarding, school outreach, thesis supervision, etc)
• org -> teams (Add pages showing the org teams #12) -> people
• org -> services used -> Git hosters -> repositories
• org -> products -> PyPi releases

The one area I am a little grey about is whether we should have a strict 1-1 relationship between project & repository in our design & terminology. The biggest implementation violation of that is https://www.openhub.net/p/coala/, which was historically a dumping ground for all repos, and we should probably clean that up more.

[gitmate-bot]

GitMate.io thinks possibly related issues are #104 (Building on forks fails), #36 (Move build into a script), #88 (Add me to coala GitHub Org), #60 (Import 2016 gsoc org data), and #59 (Import 2017 gsoc org data).

[sks444]

The one area I am a little grey about is whether we should have a strict 1-1 relationship between project & repository in our design & terminology.

IMO, it should be one to many; from a repo to projects because one repository can have many projects, right?

[sks444]

org -> products -> PyPi releases

Regarding details about PyPi packages: I am thinking of creating an app name pypi and model pypi into it. and then we can get the name of all the PyPI packages from here https://wiki.python.org/moin/PyPISimple, and then we can get all the other details related to a package using https://wiki.python.org/moin/PyPIJSON
Or maybe we can have an app name products and model pypi into it?
@jayvdb, any suggestions? :)