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 2 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
23 changes: 23 additions & 0 deletions OKR/GO_CORE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,29 @@

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.

## 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%

### 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

### Datastore works efficiently for large data sets
* Final go/no-go decision on Badger (full design comparison vs other options + final decision)
Copy link
Contributor Author

@eingenito eingenito Dec 12, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Maybe this should be something like:

A fast, stable datastore capable of supporting large data sets > (?)TB has been selected and released as experimental

Copy link
Member

Choose a reason for hiding this comment

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

That's pretty much where badger is right now

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right - good point. Maybe this OKR should be about a new default datastore that has the right characteristics for large data sets.


### 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.


### gx becomes a beloved tool by the Go Core Contributors Travis are you still working on this?
* 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 !

## 2018 Q4

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