iamtrask / deprecated Goto Github PK

For all the projects, what do you guys think of categorizing their documentation into 2 types: "Developer/Technical" (setting up dev environment, API docs, etc.) and "Product" (roadmaps, user stories), and keeping "Developer" docs in the project repo itself and "Product" docs in this repo? Or should we just have each project repo contain everything about the project?

I feel that having the language agnostic docs in this repo would help us deal with the issue of polyglot development more gracefully :)

My plan of attack is to start from the Goals of OpenMined as a whole for this POC, then the Features the individual projects need to have to accomplish these goals. After that, we'll start creating Epics, then Stories/Tasks for accordingly.

Under incentives, it's stated that "It’s also advantageous for a mine to begin training a dataset as soon as possible since the potential change gradient is higher at the beginning of training.". Under these conditions, a rational miner would be incentivized to exclusively contribute to new campaigns. Is there anything stopping a miner from simply mining the first % of a project and then jumping ship as soon as it detects that a new project is available, thus ensuring maximal reward for all mining contributed while never actually doing the hard work that gets a model trained to the point that it's useful?

User Story A: As a Deep Learning enthusiast, I want to hear about OpenMined in one of my Deep Learning Communities in such a way that I land on a page of the project that cators to my interests, explains why I might be interested in the project, and leads me through a curriculum of information that takes me through my first Pull Request into PySyft or syft.js. The curriculum should both serve as a means of conveying information and should also keep me engaged and grow my excitement around what the OpenMined Community is building.

Acceptance Criteria:

1. A Markdown file in Docs/curriculum should exist specifically for on-boarding individuals into the PySyft and syft.js projects.
2. BEGINNING: The markdown file of (1) should contain a Step 1, Step 2, Step 3 style list of pointers to various pieces of OpenMined documentation and tutorials that someone onboarding onto the Sonar Project would require to be able to know about this project. This includes ALL demos of the capabilities of the technology (whether just notebooks or in youtube videos on our channel). This Markdown file should be the appropriate next step after finishing the General "Contributor Quickstart Guide".
3. MIDDLE: along the way, there should include pointers to various tutorials external to OpenMined (such as deeplearning.ai or fast.ai courses) so that people can know where to acquire the skills necessary to contribute to PySyft or Syft.js if they do not already have them.
4. END: This markdown file should finish with steps referring to an Issues page (with appropriate filters) for identifying Issues that are relevant for new contributors to be able to pick up.
5. SUCCESS CRITERIA: While (1-4) are suggestions... the true goal here is to eliminate the need for someone to resort to Slack to be able to merge their first PR to Sonar or PySonar

User Story A: As an Ethereum enthusiast, I want to hear about OpenMined in one of my Ethereum Communities in such a way that I land on a page of the project that cators to my interests, explains why I might be interested in the project, and leads me through a curriculum of information that takes me through my first Pull Request into Sonar or PySonar. The curriculum should both serve as a means of conveying information and should also keep me engaged and grow my excitement around what the OpenMined Community is building.

Acceptance Criteria:

1. A Markdown file in Docs/curriculum should exist specifically for on-boarding individuals into the Sonar and PySonar projects.
2. BEGINNING: The markdown file of (1) should contain a Step 1, Step 2, Step 3 style list of pointers to various pieces of OpenMined documentation and tutorials that someone onboarding onto the Sonar Project would require to be able to know about this project. This includes ALL demos of the capabilities of the technology (whether just notebooks or in youtube videos on our channel). This Markdown file should be the appropriate next step after finishing the General "Contributor Quickstart Guide".
3. MIDDLE: along the way, there should include pointers to various tutorials external to OpenMined (such as to "decypher.tv" to learn how to code Solidity) so that people can know where to acquire the skills necessary to contribute to Sonar if they do not already have them.
4. END: This markdown file should finish with steps referring to an Issues page (with appropriate filters) for identifying Issues that are relevant for new contributors to be able to pick up.
5. SUCCESS CRITERIA: While (1-4) are suggestions... the true goal here is to eliminate the need for someone to resort to Slack to be able to merge their first PR to Sonar or PySonar

The docs currently state 2 conflicting messages regarding the return of trained models to Data Scientists.

Under Components: Sonar is said to return the model to the Data Scientist.
Sonar - A federated learning server running on the blockchain that handles all campaign requests, holding Bounty in trust. This library communicates with the Capsule to generate PGP keys and deliver the final, trained results back to the Data Scientist. It also communicates with miners, collecting Gradients and distributing Bounty accordingly.

Under Repositories: Capsule is said to return the model to the Data Scientist.
Capsule (Python)
PGP key generator, also responsible for delivering the trained and decrypted dataset back to data scientist

Which is it?

• Link to setup instructions for different OS's using methods highlighted on tutorial page
• Add link to tutorials as best way for getting started: https://github.com/OpenMined/tutorials
• Update slack channel names to reflect those in usage currently
• Remove deprecated repos
• Rename node.js repo to Bygone

Since we're growing rather rapidly, @iamtrask and I thought it'd be good to get the discussion going on formalizing some conventions.

Here are some to get the ball rolling:

Coding Conventions

Python: PEP8
Javascript: ES6(?)

Commits and PRs

Great reference used by another open source project I work on. This can be relaxed as much as we see fit.

Main points

• One logical step per commit (makes for easier reviews)
• Appropriate commit messages (same reason as above)
• Type of merge (squash or not)

Continuous Integration (Automated Testing, Code Quality/Style)

• Travis/Circle CI
• Sonar (heh)

User Story A: As a Node.js enthusiast, I want to hear about OpenMined in one of my Homomorphic Encryption Communities in such a way that I land on a page of the project that cators to my interests, explains why I might be interested in the project, and leads me through a curriculum of information that takes me through my first Pull Request into mine.js. The curriculum should both serve as a means of conveying information and should also keep me engaged and grow my excitement around what the OpenMined Community is building.

Acceptance Criteria:

1. A Markdown file in Docs/curriculum should exist specifically for on-boarding individuals into the related projects mentioned above. This Markdown file should be the appropriate next step after finishing the General "Contributor Quickstart Guide".
2. BEGINNING: The markdown file of (1) should contain a Step 1, Step 2, Step 3 style list of pointers to various pieces of OpenMined documentation and tutorials that someone onboarding onto these projects would require to be able to make meaningful contributions. This includes ALL demos of the capabilities of the technology (whether just notebooks or in youtube videos on our channel).
3. MIDDLE: along the way, there should include pointers to various tutorials external to OpenMined (blogs, youtube videos, tutorials, MOOCs, books, etc.) so that people can know where to acquire the skills necessary to contribute.
4. END: This markdown file should finish with steps referring to an Issues page (with appropriate filters) for identifying Issues that are relevant for new contributors to be able to pick up.
5. SUCCESS CRITERIA: While (1-4) are suggestions... the true goal here is to eliminate the need for someone to resort to Slack to be able to merge their first PR.

Normally it is a good idea to add an explicit CLA bot to all repositories where a lot of contributors contribute code.

Under normal circumstances everyone that contributes code implicitly accepts the license of the repository. However I doesn't hurt to protect ourselves from potential law suits by adding a super short explicit acceptance step using the CLA bot.

I don't mind implementing this for all the repos as I have done it before.

-To be updated-

Currently there is no order of how methods appear, for example, within the TensorBase class and in math.py. There is no strict convention for organizing methods and functions but a general pattern to follow would be:

class SomeClass(object):
    def __magic_methods__(self):
        "magic methods first, usually in alphabetical order"
    def _private_method(self):
        "worker methods next, also in alphabetical order"
    def a_method(self):
        "then normal methods, also in alphabetical order"`

User Story A: as a new user of OpenMined, I want to be able to walk through a tutorial in our Documentation that shows me how to run the functionality specified in mine.js - Issue 45

Acceptance Criteria:

• A tutorial markdown file walking through the above functionality as a demo.

Background: We're building an advanced ecosystem of repositories that all need to communicate with each other. This means that Contributors in one repository would benefit greatly by being able to read short descriptions about functionality occurring in another repository. In this Epic, we want to accomplish automatic Documentation generation for all of our repositories across OpenMined.

Acceptance Criteria:

• All repositories have a hosted documentation page that autobuilds as a subdomain of our website based on the name of the repository. (i.e., something like docs.openmined.org/pysyft OR pysyft.docs.openmined.org)

says #team_syft, should be #team_pysyft.

While trying to find the channel I have now accidentally created a #team_syft and don't have permission to delete it, so I set the channel purpose to redirect people to #team_pysyft. and left the channel.

User Story A: as a new user of OpenMined, I want to be able to walk through a tutorial in our Documentation that shows me how to run the functionality specified in mine.js - Issue 44

Acceptance Criteria:

• A tutorial markdown file walking through the above functionality as a demo.

User Story A: As a Homomorphic Encryption enthusiast, I want to hear about OpenMined in one of my Homomorphic Encryption Communities in such a way that I land on a page of the project that cators to my interests, explains why I might be interested in the project, and leads me through a curriculum of information that takes me through my first Pull Request into PyAono, PyYASHE, PyBV, or PySyft. The curriculum should both serve as a means of conveying information and should also keep me engaged and grow my excitement around what the OpenMined Community is building.

Acceptance Criteria:

1. A Markdown file in Docs/curriculum should exist specifically for on-boarding individuals into the related projects mentioned above. This Markdown file should be the appropriate next step after finishing the General "Contributor Quickstart Guide".
2. BEGINNING: The markdown file of (1) should contain a Step 1, Step 2, Step 3 style list of pointers to various pieces of OpenMined documentation and tutorials that someone onboarding onto these projects would require to be able to make meaningful contributions. This includes ALL demos of the capabilities of the technology (whether just notebooks or in youtube videos on our channel).
3. MIDDLE: along the way, there should include pointers to various tutorials external to OpenMined (blogs, youtube videos, tutorials, MOOCs, books, etc.) so that people can know where to acquire the skills necessary to contribute.
4. END: This markdown file should finish with steps referring to an Issues page (with appropriate filters) for identifying Issues that are relevant for new contributors to be able to pick up.
5. SUCCESS CRITERIA: While (1-4) are suggestions... the true goal here is to eliminate the need for someone to resort to Slack to be able to merge their first PR.

The aim here is to come up with a structured and transparent workflow/process that we will use to decide what goes into each release. This can then be standardized in all of our projects, which will be extremely useful when we have different PMs for each project.

The approach I'm leaning towards to is Story Mapping, described here.

I'm trying to wrap my mind around how we might guide new users exploring OpenMined for the first time to join a specific project. It's hard for people to grasp the entire ecosystem and so often they join Slack without much aim of where they can best fit in. If we formed teams, naturally this might fall into place... but for the time being, we need some means of directing people according to their skills and interests. I would propose the following system (i.e. Machine Learning):

Machine learning

Repositories:

• PySonar - Python client to blockchain application (Sonar)
• PySyft - Python deep learning library
• syft.js - Node.js deep learning library (for web and mobile browsers)

Slack channels: #sonar, #syft

This gives people a high-level overview of what repositories are important and what Slack channels contain the primary discussion on the matter. Other things we could do would be to include a link to the top contributors of a project (so they can be accessible for DM by an individual to get caught up). These individuals would act as pseudo "team leaders" basically implied from how much they've contributed to a project. We also may want to include a link to the issues pages directly so that people can see the actual work that needs to get done.

Open for thoughts here. I've already begun addressing this in the following pull request. Please feel free to contribute and discuss!