docs: 2018 Q3 OKRs #1409
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,6 +2,30 @@ | |
|
|
||
| We try to frame our ongoing work using a process based on quarterly Objectives and Key Results (OKRs). Objectives reflect outcomes that are challenging, but realistic. Results are tangible and measurable. | ||
|
|
||
| ## 2018 Q3 | ||
|
|
||
| **The Connectivity Magic story is figured out and solved** | ||
|
|
||
| - A js-ipfs Daemon will always find other IPFS Daemons (js & go) in the LAN | ||
| - The rendezvous protocol is a sound solution for DApps (e.g. PeerPad & others) | ||
| - The DHT is enabled by default in js-ipfs | ||
|
There was a problem hiding this comment. In this KR, the implicit things are:
|
||
| - Handles correctly a scenario where the number of Connections grows (through Conn Management Strategy) | ||
|
There was a problem hiding this comment. In this KR, the implicit things are:
|
||
| - ... MOAR :D | ||
|
|
||
| **Daemon is as reliable as it can be** | ||
|
|
||
| - A Daemon runs for 10 days without a crash | ||
|
There was a problem hiding this comment. In this KR, the implicit things are:
|
||
| - One or more js-ipfs daemons are part of the Bootsrapper nodes | ||
| - js-ipfs can handle 1TB of data, both Node.js and Browser. | ||
| - npm on IPFS over js-ipfs is a sound way to install deps and gets used for CI | ||
| - ... MOAR :D | ||
|
|
||
| **New user/contributor experience is extraordinary** | ||
|
There was a problem hiding this comment. @hugomrdias I've a few questions based on your suggestions:
There was a problem hiding this comment. codesandbox gives the developer an environment very similar to a local dev environment but inside a browser. You can require/import, bundle, lint, etc. It has integration with github and deploy providers like Now. Even the UI/UX is very similar to popular editors.
About bundlers, it's not about being hard to use, it's more about being as easy as possible. Both webpack and parcel provide zero config functionality and we need to make sure ipfs is supported by those default configs. Another thing is, the community is starting to run their bundlers through the complete dependency tree and not use the pre-bundled files from packages, we need to make sure ppl can run webpack/babel through ipfs complete deps tree and still work without errors. An example of this was the work i did to make ipfs work with create-react-app 2.0. Another topic is size, do we have the best require patterns to enable the best bundle sizes from these bundlers? ex. #1414 |
||
| - js.ipfs.io is finished and published | ||
| - ... MOAR :D | ||
|
|
||
|
There was a problem hiding this comment. It's time to wrap this up. @alanshaw @achingbrain @hugomrdias, ideally, each should have at least 4 KRs with two of them being a P0. Right now the KR distribution is kind of unbalanced and it is not giving you a set of problems to focus. Also, I'm not confident that the list is as polished as it can be for the Objectives we have. Now that the Dev Meetings happened and your understanding of the whole project expanded vastly, I want you to go through these again and come up with new proposal. Please put this as your top priority until we freeze KRs next Wednesday. There was a problem hiding this comment. I didn't appreciate the time frame on the switch to base32 until the developer meetings. I'm happy to spearhead the development work that needs to happen on the JS side of things for this. BTW this is a P0 for In Web Browsers OKRs. I'm also going to continue to be involved with the WebUI rebuild as part of the GUI WG. |
||
| Once these OKRs are finished, you will be able to find them on the [2018 Q3 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/19vjigg4locq4fO6JXyobS2yTx-k-fSzlFM5ngZDPDbQ/edit#gid=274358435) | ||
|
|
||
| ## 2018 Q2 | ||
|
|
||
| Find the **js-ipfs OKRs** for 2018 Q2 at the [2018 Q2 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/1xIhKROxFlsY9M9on37D5rkbSsm4YtjRQvG2unHScApA/edit#gid=274358435) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's continue discussing the OKRs over the markdown, taking inspiration from the notes already shared in this thread.
I've defined 3 main objectives (rewording is welcome if you see the need) for this quarter which capture the most requested and needed features and bug fixes.
Let's shoot to get the final list of KRs by Wednesday, final review on Thursday and ship it on Friday.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alanshaw @hugomrdias @achingbrain. I went again through your list of suggestions and completed the list of KRs. Please review:
I've assigned some KRs already, given that they are a continuation of previous work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it's worth having a 'technical debt' section for things similar to the CI testing time item?
Feature parity with the go API would also be a good thing to shoot for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI testing time is contemplated in the third objective.
What features (APIs) do you feel js-ipfs urgently needs that go-ipfs has that are not captured by the current OKRs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The biggest pain for me at the moment is the DAG API being incomplete.
Also
npm-on-ipfsneedsipfs.name.resolveandipfs.name.publishwhich I don't think are implemented yet although I guess that would be captured by the 'make npm-on-ipfs a thing' OKR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@achingbrain IPNS is landing this quarter by the libp2p team. Note that publishing and resolving names is for sharing the registry only, all the rest should work without it which is the bulk of the challenge.