2018 Q4 OKR Planning #5474
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| # Quarterly Objectives and Key Results | ||
|
|
||
| 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 Q4 | ||
|
|
||
| **go-ipfs handles large datasets (1TB++) without a sweat** | ||
| - `P0` - It takes less than 48 hours to transfer 1TB dataset over Fast Ethernet (100Mbps) | ||
| - `P0` @hannahhoward - List a sharded directory with 1M entries over LAN in under 1 minute, with less than a second to the first entry. | ||
| - `PX` - There is a prototype implementation of GraphSync for go-ipfs | ||
|
There was a problem hiding this comment. somewhat dependent on js-ipfs graphsync There was a problem hiding this comment. @hannahhoward already thinking about speeding up directories and may have knowledge of how to implement (but needs a partner for spec work) |
||
| - `P0` @schomatis - There is a better and more performant datastore module (e.g Badger or better) | ||
|
There was a problem hiding this comment. @kevina would also like to be somewhat involved with this. |
||
| - `P1` - Rewrite pinning data structure to support large pinsets and flexible pin modes | ||
|
There was a problem hiding this comment. @kevina interested in contributing to this - not sure about owning per say yet =] There was a problem hiding this comment. I spent a very small amount of time working on something related to pinning and so I'd be interested in contributing to this objective. I think with enough support maybe I can own it, but I'd need to discuss that with someone who knows more about the system and the OKR to determine whether or not that is reasonable. And I don't want to step on your toes @kevina, if you are motivated to own this work. There was a problem hiding this comment. Link to the previous discussion: #5474 (comment) To clarify my interest. I think this task will be made a lot easier with some architectural changes to the blockstore. I wrote up my first draft of such changes in #5528. I also think that we should use a snapshot based approach to G.C. and completely avoid the need for read and write locks (but with perhaps mutexes that will be held for short durations). In order for that to happen we will need some additional changes. Once I write up this proposal I would like it to be given some serious thought as I think it can solve a lot of problems we are having. If we agree to these changes I will gladly take lead to help push it though, although completing it in Q4 may be to aggressive a strategy. I get the general sense that others would generally like to avoid any architectural changes and instead attempt to solve this with an independent data structures. I personally see this as creating additional complexity so I not sure I can agree with this approach. Thus, if we go down that path I probably not a good person to lead this. There was a problem hiding this comment. So, there are two issues here:
|
||
|
|
||
| **The bandwidth usage is reduced significantly and is well kept under control** | ||
|
There was a problem hiding this comment. I like the idea of contributing to this objective, but I'm probably not the best person to own it. There was a problem hiding this comment. @Stebalien who do you suspect should own these OKRs? In the absence of a more qualified person (and in an effort to move important goals forward), I'm willing to take on some or all ownership. If there's a better owner, then I can work with them towards this objective. |
||
| - `P1` - Spec and draft implementation of allowing users to opt out of providing every IPLD node (and only provide root hashes) | ||
| - `P0` - Bitswap improvements reduce number of duplicate blocks downloaded by 75% | ||
| - `P0` @stebalien - The number of messages sent by Bitswap is on average <= 2x the number of blocks received | ||
|
|
||
| **It is a joy to use go-ipfs programatically** | ||
momack2 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - `PX` @magik6k - The Core API is finalized and released. Make it easier to import go-ipfs as a package | ||
|
There was a problem hiding this comment. what is a good priority for this? |
||
| - `PX` @magik6k - go-ipfs-api exposes the new Core API | ||
| - `PX` @magik6k - go-ipfs Daemon, Gateway, and cmds library use the new Core API | ||
| - `PX` @magik6k - The legacy non Core API is deprecated and the diagram on go-ipfs README is updated | ||
|
|
||
| **go-ipfs becomes a well maintained project** | ||
momack2 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - `P2` @eingenito - The Go Contributing Guidelines are updated to contemplate expecations from Core Devs and instructions on how to be an effective contributor (e.g include PR templates) | ||
| - `P1` @eingenito - A Lead Maintainer Protocol equivalent is proposed, reviewed by the team, merged and implemented | ||
| - `P0` @eingenito - Every issue on https://waffle.io/ipfs/go-ipfs gets triaged (reviewed and labeled following https://github.com/ipfs/pm/blob/master/GOLANG_CORE_DEV_MGMT.md) | ||
| - `P0` @eingenito - Every non-trivial PR is first reviewed by someone other than @Stebalien before he looks at it. | ||
| - `P2` - Every package has tests and tests+code coverage are running on Jenkins | ||
| - `P2` - There is an up-to-date Architecture Diagram of the Go implementation of IPFS that links packages to subsystems to workflows | ||
| - `P2` @schomatis - go-unixfs is more maintainable with improved code, comments and documentation | ||
|
|
||
| @momack2 Could you help me phrase these ones with a KR-oriented approach? | ||
|
|
||
| **gx becomes a beloved tool by the Go Core Contributors** | ||
momack2 marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Who has made major changes to gx in the past? Is it only @whyrusleeping? Are these actually appropriate for someone else to pick up? There was a problem hiding this comment. @travisperson will probably take these (and @schomatis has been doing some gx work). We have a long discussion here whyrusleeping/gx#179 culminating with an offline discussion between @whyrusleeping, @travisperson and I (key points here whyrusleeping/gx#179 (comment)). There was a problem hiding this comment. Thanks. @travisperson are you comfortable with my adding your name to these OKRs? Are they pretty accurate as stated, and might they belong in another project? There was a problem hiding this comment. @eingenito ya, these looks good. |
||
| - `P0` @travisperson - You can update a minor version of a transitive dependancy without updating intermediate dependancies | ||
| - `P0` @travisperson - go-ipfs doesn't have checked-in gx paths | ||
|
|
||
| **Complete outstanding endeavours and still high priorities from Q3** | ||
| - `P0` @kevina - base32 is supported and enabled by default | ||
| - `P1` - go-ipfs gets a unixfsV2 spec and prototype | ||
| - `P2` @djdv - Add mutable methods (r+w) to the new mount implementation and get it building+tested on all supported | ||
| platforms | ||
| - `P1` @schomatis - MFS behavior and implementation is performant and correct | ||
|
|
||
| ## 2018 Q3 | ||
|
|
||
| Find the **go-ipfs OKRs** for 2018 Q3 at the [2018 Q3 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/19vjigg4locq4fO6JXyobS2yTx-k-fSzlFM5ngZDPDbQ/edit#gid=274358435) | ||
|
|
||
| ## 2018 Q2 | ||
|
|
||
| Find the **go-ipfs OKRs** for 2018 Q2 at the [2018 Q2 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/1xIhKROxFlsY9M9on37D5rkbSsm4YtjRQvG2unHScApA/edit#gid=274358435) | ||
|
|
||
| ## 2018 Q1 | ||
|
|
||
| Find the **go-ipfs OKRs** for 2018 Q1 at the [2018 Q1 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/u/1/d/1clB-W489rJpbOEs2Q7Q2Jf1WMXHQxXgccBcUJS9QTiI/edit#gid=2079514081) | ||
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.
Is there any existing description of the path to achieving this OKR? Is it related to or independent of the effort to minimize duplicate blocks? And I'm assuming it's apart from any DHT traffic. So is it smarter sessions, or improved I/O path, or datastore speed? Or is it a protocol change like graph sync?
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.
... and, some of these OKRs are challenging to assign (or take ownership of) because they seem like a collection of features and improvements that may well be worked on by multiple people.