OKRs - 2019 Q2 DDC

[jimpick]

Parent issue: #902

TODO:

• Score your 2019 Q1 OKRs with End of the Quarter Scores
  Note: because of de-scoping, we diverged a lot from the OKRs for this quarter, so we're not going to spend a lot of time reconciling.
• Q1 Retrospective
• Async Brainstorming
• Move 2019 Q2 OKRs to 2019 Q2 OKRs Spreadsheet
  • draft ideas for Q2 projects, using the central priorities agreed on here as reference

@pgte @aschmahmann @parkan

[jimpick]

OKR planning status update:

Today (Thursday) I had some quick 1:1 zoom chats with @aschmahmann and @parkan to brainstorm ideas for OKRs.

On Friday, I'm going to chat with @momack2 ...

I also want to touch base with @pgte as soon as timezones/availability permits (we started our OKRs later than everybody else).

On the Brainstorming PeerPad, I pulled out the KRs from the IPFS Q2 "masterplan" (as I'm referring to it) that either refer to us or which we might be able to push forward.

Here are some thoughts on how we could slice and dice the OKRs:

IPFS Camp

Obviously, we want to be prepared for IPFS Camp - I wouldn't be surprised if we spend 50% of the time in Q2 on preparations for that + IPFS Team week.

IPNS + friends

IPNS work is proposed as a P0 priority to support Package Managers. This fits well with the work plan that @aschmahmann has been building. @pgte and @aschmahmann have been comparing notes and making some plans for IPNS, so I think that together they should be able to identify some OKRs for that. When I say "IPNS", I'm using that as a shorthand ... I think it covers related work needed on things like GossipSub and CRDTs too.

PeerPad / peer-base maintenance

I think that PeerPad and peer-base can take a back seat this quarter. I'd like to cut the main https://peerpad.net/ site over to the new code as soon as possible (without a big noisy launch) and keep the library dependencies up-to-date, but perhaps limit that to a week or so of work for Q2. PeerPad currently should be stable enough for some informal testing and usage. The new peer-base-pinner should prevent data from being lost.

"Integrations"

Here are some thoughts I had after discussing ideas with Arkadiy...

I think the DDC working group could be the home of a unique "integrations" role which is able to cut across working group boundaries and build up expertise covering the whole IPFS suite of projects. The main focus of the "integration" work would be to rapidly stitch together small projects that exercise the latest code emerging from the more feature-focused working groups such as go-ipfs, js-ipfs, libp2p, IPLD, ipfs-cluster, etc.

Because DDC is deeply embedded within the IPFS organization, we can cultivate the ability to try out new features before they fully baked, and provide immediate, direct feedback to the feature teams.

For "integrations" work, I think we'd steer away from creating new features ourselves -- instead, we'd try to use the APIs that are being built by the feature-focused working groups. Over time, we will become experts in implementation details and we will try to be the first to identify bugs and provide small fixes. I'd like to see us build up the ability to build complex simulations using Testlab.

I think that resources that collectively provide the "integrations" role could be optimized so that they are always "on call" to give short-term boosts to the output of internal collaboration partners, such as the Package Managers WG, IPFS-in-web-browsers WG, LOCol WG, Community WG, and even Filecoin and SourceCred. They could even step into documentation and QA roles to fill short-term gaps if needed. Quickly formed "tiger teams" could "sign out" resources from "integration" to hit the ground running without having to drain other working groups of resources.

Additionally, resources could also be allocated for short-term external collaboration work with outside partners. In the run-up to IPFS Camp, I think there's going to be a lot of demands to become knowledgeable in the work that our outside collaboration partners are going to bring to the conference.

I think that an in-house "integrations" role would be able to share some of the project management infrastructure that is already in place to manage our work with agencies and consulting shops. DDC already has a history of working with Moxy on Discussify, IDM, and other projects. The number of resources committed to "integrations" could scale elastically, with a core staff within DDC (initially just me) - but it could be supplemented with agencies we contract, borrowed staff from other working groups, and possibly even students/interns or open source community volunteers.

These are just rough ideas right now ... for Q2, if Pedro and Adin are focused on IPNS, I might be the sole resource for "integrations" - so it would just be a fraction of my available hours. If this is an idea worth pursuing, we'd need to figure a decision making system for how to split those hours between internal and outside collaborations.

[pgte]

@jimpick
While I think that the integrations team is very necessary, I wonder what's the reasoning of it falling under the DDC umbrella other than having experience with third parties. (IMO, these third-party use cases (discussify and IDM) rarely consisted of direct IPFS usage, (mostly because it would be very hard to build these types of applications on top of IPFS directly)).
In my head, it would make more sense that this fell into Collaborations or a new Integrations working group — I believe that it's weird to extend (and cut) the original scope of the working group.

[jimpick]

@pgte I don't think that "integration" or "collaborations" necessarily needs to fall under the DDC umbrella ... but for the immediate future, I think it could be a need and a role I could fill, and it could be "incubated" inside DDC until it's proven enough that it's worth the overhead of creating a new working group for it.

Right now, I can't think of any other development focused working groups within the IPFS organization that build things with all parts of the stack, so I think the incoming requests naturally come to us. I'm proposing that we "isolate" those requests into a formalized stream so we can service them without distracting resources from our pre-planned work streams (eg. IPNS).

[jimpick]

I chatted with @pgte and @momack2 today ... good conversations.

One thing that I'd like to capture was the idea of a "reverse-proxy developer advocate" ... we can act sort of like a proxy for all the outside community developers that use IPFS, and work with the internal teams building features to provide feedback - sort of the mirror image of what a developer advocate / developer relations team does.

[momack2]

More notes from @jimpick and my chat this morning:

• Happy to have these "integrations" OKRs live in the Project WG sheet for next quarter along with our existing workstreams on collaborations and cross-wg support. Seems like that could be a logical fit and keep Jim's useful work near @parkan and myself as prioritization stakeholders. The P0 is we take on the right work, not logistics of where it lives. =]
• In this integrations thread, there's interest in utilizing testlab (cc @bigs) for some scalability testing for peerpad // package managers --> question for @andrew and @achingbrain if there are some benchmarks for npm-on-ipfs, apt-on-ipfs, or other generic PM-relevant use cases that would benefit from Jim's dev support.
• An obvious goal for the beginning of the quarter is to launch the dev.peerpad.net version to prod and ensure it's usable for internal dogfooding / demoing
• some brainstormed OKRs re integrations
  • work with 4+ external partners to prepare installations/talks/demos for IPFS Camp
  • create 2-3 demos for different use cases combining the suite of IPFS tools and publish as how-to guides
  • Support top-priority collabs with XXhrs (48?) of dev-support time
  • Stress-test X new/experimental features in real-world application conditions and report back bugs/pain points

[jimpick]

Our OKRs are now moved to the spreadsheet, ready for comments.

https://docs.google.com/spreadsheets/d/1YSeyWqXh3ImanRrTkYQHHkCofiORn68bYqM_KTLBlsA/edit#gid=27675624

[andrew]

For apt-on-ipfs (using go-ipfs) it currently takes ~1 minute to publish the root to IPNS /ipns/QmTeHfjrEfVDUDRootgUF45eZoeVxKCy3mjNLA8q5fnc1B

I'm not sure if npm-on-ipfs (which uses js-ipfs) is using IPNS yet as it's not connected to the DHT.