Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

OKRs - 2019 Q1 Go Core Dev #794

Merged
merged 7 commits into from
Mar 18, 2019
Merged

OKRs - 2019 Q1 Go Core Dev #794

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
95f7617
2019 Q1 Go Core Dev OKRs
Dec 10, 2018
0409db9
Update GO_CORE.md
Dec 12, 2018
97e9aa1
Update GO_CORE.md
Dec 18, 2018
90c2102
Update GO_CORE.md
Dec 19, 2018
81f7724
Update GO_CORE.md
Dec 19, 2018
e39e7be
Adding Q1 endeavors from 2019 roadmap
momack2 Feb 1, 2019
bbff547
move OKRs to sheet and add link
momack2 Feb 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 32 additions & 1 deletion OKR/GO_CORE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,38 @@

We 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
## 2019 Q1

### Data transfer is fast and efficient
* It takes less than 48 hours to transfer 1TB dataset over Fast Ethernet (100Mbps)
* Bitswap refactor + improvements reduce number of duplicate blocks downloaded by 75%
* Transfers of sparsely provided data are roughly as efficient as fully provided content

### Adding and providing large data sets works efficiently
* Create Provider Strategies system that is solely responsible for providing
* Implement provider strategy such that a user can add (and provide) npm or tr-wikipedia without turning off providing and without significantly impacting finding content
momack2 marked this conversation as resolved.
Show resolved Hide resolved

### Datastore works efficiently for large data sets
* Complete development of benchmarks to test speed and reliability across a wide range of datastore sizes
* A new datastore implementation, suitable for very large data volumes, is adopted as default in go-ipfs

### go-ipfs becomes a well maintained project
* Every non-trivial PR is first reviewed by someone other than @Stebalien.
* A work-tracking process is adopted that allows the team to easily track the highest priority unclaimed issues, see the status of in progress work, and know which PRs need review, easily.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to make this push after we get the CoreAPI in place and after we get the new RPC system. Basically, I'd like to avoid spending too much time documenting interfaces that are going to be deprecated.

@momack2 convinced me that ignoring documentation is a bad idea (ok, fine...) and suggested

  • Every file with a non-trivial change gets fully documented.

Yes, this is going to be hard, but I think that's the only way we're going to make this happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌 this allows us to improve and update our documentation incrementally as we touch/grok the code in service of our Q1 efforts. To measure this, we can pull all changed files in Q1 and check documentation coverage (and maybe spot-check documentation quality to ensure it's above par). Our goal with updating the docs is to make it easier for other contributors (new or old) to quickly onboard on modules and help move them forward.


### go-ipfs is easy to integrate
* A new flexible and performant RPC API is designed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think CoreAPI and Base32 actually fall under this objective.


### gx becomes a beloved tool by the Go Core Contributors
// Topic under intense discussion!
* Find a full-time developer for gx!
* go-ipfs doesn't have checked-in gx paths
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@travisperson is this still a goal of yours? I don't know if you're still working on gx udpates or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a goal should be to either onboard a contributor/full-time maintainer excited about pushing gx forward (@warpfork - any ideas from recent conferences?) and really double down on making this a powerful proof of concept that is friendly and useful for go developers, or adopt @Stebalien's proposal to optimize for developer velocity in the short/mid term.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah - absolutely agree; one of those is going to be an OKR. And possibly even both.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Optimizing developer velocity" could be the objective. The KR would be "go-ipfs developers are no longer adversly affected by gx" (with some significant rewording). That way, either getting a maintainer or moving away from gx are valid solutions.


### Complete outstanding endeavours that are still high priorities from Q3
* base32 is supported and enabled by default
* CoreAPI refactor is completed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added the following to the spreadsheet:

  • New fuse mount implementation replaces the existing one.


## 2018 Q4certifi

- [go-ipfs 2018 Q4 OKRs](https://docs.google.com/spreadsheets/d/139lROP7-Ee4M4S7A_IO4iIgSgugYm7dct620LYnalII/edit#gid=1720716278)
- [Open Planning Thread](https://github.com/ipfs/go-ipfs/pull/5474)
Expand Down