#Countdown to Kubecon

1 messages · Page 1 of 1 (latest)

craggy jungle
#

@vast coyote 👋 🙂

#

I finished my cleanup pass on the linear project

#

I feel like we need to decide if we want to go all in on using that project (and that tool) to coordinate the countdown

#

In the past we've used it mostly as a loose collection of thoughts, but haven't been on top of it the way we are with github

#

I know it's awkward because, for one, non-employees don't have access to Linear - not ideal

#

I worry about tooling ambivalence leading us back to lack of clarity and as a result, important work falling through the cracks

#

wdyt?

vast coyote
# craggy jungle I feel like we need to decide if we want to go all in on using that project (and...

I think we should centralize in Linear; we recently did add a bunch of GH issues related to various Zenith bugs/papercuts, but for actually organizing+planning Linear is way way better.

This gets back to all the stuff we talked about in Lisbon and are working on now, but ideal in my mind would be a one-way sync from GH->Linear so we can still track those OSS issues in Linear for planning.

But in meantime I would be happy to do that by hand

#

If we don't have a "Kubecon" label in Linear, that would be helpful.

craggy jungle
#

I completely agree re: one-way sync. My thinking is that in the end, Github will be a place of discussion and collaboration with the community on bug reports and feature ideas. A specialized form of support, really, And Linear will be the place to actually do the work. One-way sync from Github, just like we do one-way sync from Intercom for paying customers, is the right fit for that.

#

But... I don't think we should count on that kind of automation for Kubecon 🙂 We can set it up after IMO

vast coyote
#

Just in terms of timing, my goal today is to finish up the refactor of sdk module stuff to enable Python modules to be written starting next week.

After that, another pass of Linear issues where we apply labels for Kubecon requirements seems like a good next step (thank you btw for the cleanup, it had languished for a long time obviously). Then we can just start farming out tasks and squashing them.

#

There's nothing big left in terms of features I think, just a lot of polish, demo-building and docs.

#

So I'll go label everything up in those categories after I finish this

craggy jungle
#

I don't think you need a label necessarily, just use the project itself as the scope.

  • If it's in scope for Kubecon, it's in the project
  • If it's not in scope, it's not in the project
inland hawk
#

Do we need a "GetSecret"? That was one thing that came up (also good thing we went with loadSecretFromID :P)

craggy jungle
#

Also, I recommend making aggressive use of sub-issues, to keep the top-level clean and useful

vast coyote
craggy jungle
#

This is the entire project at the moment

Screen_Shot_2023-10-13_at_8.22.41_PM.png
vast coyote
#

So not much left afaict

craggy jungle
random flint
craggy jungle
vast coyote
craggy jungle
#

In a nutshell, the decision I would like us to make right now is:

  • We're going to use that Linear project as our source of truth for shipping Zenith at Kubecon
  • We're setting a high quality bar for the issues in there: context, accuracy, etc. Same bar we've set in the past for our github issues
  • We will all pitch in to reach that quality bar
  • It's OK to call each other out, ie. "would you mind updating that in the issue", etc
  • @vast coyote is the project lead so if our issues suck, it's all his fault and he buys drinks at Kubecon 😛
vast coyote
craggy jungle
#

FYI @spare kiln @vestal leaf @modern haven @weary vapor 👆

#

Weird, I removed a bunch of issues from the project yesterday but I still see them??

#

@modern haven is there an automation that moves issues with certain labels to certain projects?

vestal leaf
craggy jungle
#

@vast coyote when something is out of scope, don't hesitate to just remove from the project. I make sure there's at least one label with "zenith" in it, so I know we can fish it out later

vestal leaf
craggy jungle
#

I do 🙂

vast coyote
craggy jungle
#

A few more linear thoughts while I'm stuck on this plane...

#
  • Random thought for later: in addition to one-way sync from github to linear. It would be cool if we organized our Linear such that the open-source work, even though it's organized in Linear, is still accessible to the community in some way. I was thinking a combination of 1) rendering a web view of the relevant issues, so that the community can follow the open-source work, including design bikeshedding etc. 2) active contributors and maintainers that don't work at Dagger, could still get Linear access, scoped to the open-source part, to participate in the actual work
vast coyote
#

I converted the Kubecon-relevant GH issues w/ Zenith label and others I found over to Linear.

I included links back to the GH issue in each Linear issue. Based on above discussion I think that when there is a corresponding Github issue:

  1. Comment on the GH issue as much as possible
  2. Use linear for tracking status + organizing
  3. Any internal-only discussion about assignments and such can go on the linear issue too

That will allow external users (and sdk developers) to still participate in discussion, so seems like the right place to start now 🤷‍♂️ But if it ends up being confusing/unproductive, then just speak up and we can figure out whatever is best for now. Given the deadlines it's probably worth having a strong bias for whatever is most efficient for everyone for the next few weeks.

(not gonna tag everyone due to Friday Night, will on Monday so everyone sees 🙂)
EDIT: @here

modern haven
weary vapor
# vast coyote I converted the Kubecon-relevant GH issues w/ Zenith label and others I found ov...

This sounds good to me - I think we should have a very strong preference for keeping discussions related to the core engine on GitHub wherever possible. I've been on the other side of the wall for other projects where discussions are often had internally, and it definitely creates distance between the community and the maintainers, which I think we don't want. Keeping as much as we can in the open, keeps the barrier that little bit lower, and makes it easier for external contributors to get involved 🙂

craggy jungle
# weary vapor This sounds good to me - I think we should have a very strong preference for kee...

Here’s my dilemma.

on the one hand yes, we want to have these discussions in the open. 100% agree.

On the other hand, we want to have these discussions in linear. It’s not sustainable to discuss all things engine (our primary product) in github while trying to adopt Linear. The monopolistic network effects of github are too strong.

So bottom line, our options are:

  1. Find a way to make our linear open
  2. Abandon Linear as our source of truth
  3. Equivocate and have the same conversation in 3 months, with everything slightly more frustrating
vast coyote
# craggy jungle Here’s my dilemma. on the one hand yes, we want to have these discussions in th...

In the "make our linear open" route, I think it would be crucial for external users to also comment on issues that are e.g. bug reports, feature requests or design discussions that are directly relevant to them.

So really the only realistic route I'm aware of that would enable both that and still allow Dagger to comment on the issues directly in Linear would be some sort of two-way sync setup.

If however, we're okay with tracking + private conversations being on Linear but public conversations being on linked GH issues, then the one-way sync is still viable. I'm not sure yet how frustrating this would be in practice. I think it might be just small enough a speed bump to not really bother us in practice, but it's borderline.

@modern haven have we already looked into all this? Just don't want to repeat conversations we've already had elsewhere.

Also, the label idea sounds great in the meantime, I'll go apply that quick

craggy jungle
#

Fwiw I think Github is to blame, for intentionally blurring the lines between support tickets and engineering tasks in a single tool, and locking it into their monopoly on open source projects

#

I think having a world-readable, contributor-writeable linear where we discuss design, priorities, assignments, dependencies etc is fair, and respects the spirit of open-source pre-github monopoly. It’s the equivalent of -dev mailing lists

weary vapor
#

Seems like a slightly contrived example, but that's how I actually did my first major open source contributions 😛

craggy jungle
#

In a perfect world with unlimited engineering resources, the answer would be: anyone can participate with a Dagger account, via linear sso

modern haven
#

@vast coyote , I tried a sync before. We should hold off on making any changes until @craggy jungle returns from vacation. A label is a great start.