basic how-to-run-it questions

[LeeBreisacher]

I'm trying to learn the basics of owid-grapher with an eye toward contributing (I am a soon-to-be-retired long time developer looking to keep my brain active). I have all the various pieces installed (VSCode, git, node, etc, etc), and I have read all the md files. I can run the basic dev setup ('make up' from the root), but I want to try debugging in VSCode and cannot quite see how to get that going. In general, I want to know if creating a "Discussion" item like this is the right way to ask questions, or is there something more "active" like Slack or Discord or similar? Thanks.

[danyx23]

Hi Lee, welcome! Sorry for the late reply, the dev team was meeting in person last week and we mostly stayed offline.

Discussions are a great way to ask these questions, as others can benefit from the information shared this way.

I assume you are interested in being able to debug the admin server? The way I do it is to run make up, then go to the admin pane and kill it with CMD/CTRL+B x, then start the admin process in a debugger in VS Code in the debug side panel (Launch admin server (via fnm)). Does that work for you? It might also be possible to use the attach to process feature, but I've never used this.

Is there a particular area that you would be interested in contributing to? What areas of web development are you familiar with?

We develop this codebase according to the needs of our organisation, and so our staff engineers are often in a better position to make larger contributions, as external contributors often lack some context. To be honest, in the past, we usually found it hard to make external contributions net-positive for us. Every collaboration is different, though, and you are by far the most experienced engineer to reach out to us, so I'd be happy to see where this one will go!

Two areas that might be good starting points for contributions come to mind:

• Documenting our setup better. As you noticed, our developer setup is only rudimentarily documented. This makes it hard for people to get started. We often don't noticed all the papercuts anymore, but for you they are fresh on your mind. If you channel this knowledge into written documentation, that would be very valuable.
• We have several issues tagged soonish-and-small. We think that they should not be major projects to implement - although for a first time contributor they may take quite a while to understand. Our users recently requested these features, so we'd be keen to have them fixed. If you want to work on one of these, it is best to ask in the issue if it makes sense for you to try and tackle this one and continue the discussion there.

Let me know if you could get the debug setup working and what you think about the other points!

[LeeBreisacher]

Thanks for the nice reply - I was starting to think maybe OWID is not the place for me, but good to hear you were together in person (I have worked remotely at home for many years, always enjoyed the few times when we were together in person).

I assume you are interested in being able to debug the admin server?

I think so? I was thinking I would set breakpoints in the backend and single step so I can see what's happening. That is usually a good way to learn things. I tried using Terminal/RunTask... in VSC, chose task "start(full)" and got: "docker-compose.full.yml: no such file or directory". So it looks like tasks.json in .vscode is out of date, or docker-compose.full.yml is missing? I'll try your suggestion for debugging. I am still employed full time until about the end of May, so I'm just tinkering a bit on the weekends until then.

Is there a particular area that you would be interested in contributing to?

In general, whatever needs doing. But I do have a particular interest in maps. I noticed this item (and related): #4697. That's obviously big with a sizeable learning curve, but you asked, so..

What areas of web development are you familiar with?

TBH, I've not done much web development. I've done many years of Java backend work. But I'm basically familiar with lots of things, and I learn quickly. As you said, I'd be happy to see where this will go.

Documenting our setup better

I am happy to try improving documentation, but that's likely to take some time before I'm comfortable/knowledgeable enough. OTOH, documentation is the kind of thing that can be gradually improved.

We have several issues tagged soonish-and-small

Yes, I noticed those. I was thinking I'd pick one and see what I can do, just to get started and have something concrete to learn on.

[danyx23]

Nice! I have to warn you though, modern front end development is a bit of a beast 😅. I did mostly backend/desktop development myself until ten years ago and was really surprised at all the complexity and the sheer amount of different technologies one needs to understand in frontend dev.

Most of our issues in this repo concern client-side code. Debugging the backend is occasionally useful, but it's probably more important that you establish an understanding of how to debug our frontend code in the browser.

It sounds like the most sensible thing is then for you to continue poking at our codebase and build up a mental model - maybe reading closed issues descriptions, checking out a version before the PR was merged, trying to give it a shot, then comparing with the solution that we came up with can be a good strategy that will also give you a sense for whether this is something you would enjoy.

When you feel you are ready, ping us in one of the soonish-and-small issues, and we can see if they are a good candidate for you to take on - looking forward!