Invitation to VizCon 2 - 12-16 March 2020

Community
,
1

Dear everyone,
In case you haven’t seen the announcements on Slack, this is an invitation to join the second Julia VizCon in Berlin 12-16 March this year. The VizCon is a working meeting for anyone wanting to contribute to the plotting and visualization ecosystem of Julia. We’ll have presentations and discussions but mostly, we’ll focus on coding together! You can see a report of last year’s vizcon here: Vizcon , 29th-30th Oct Berlin (first method in the thread only).

The idea is to focus on areas of the plotting/visualization ecosystem in Julia and try to give some areas a “quantum leap”. Often a really concerted focused effort on a package can give it that push to become much more broadly useful. What exactly we do is up to everyone attending, but ideas for this year includes making Makie compatible with RecipesBase recipes (which would allow it to plot types from hundreds of packages), and @simondanisch will bring a plan and a prototype for this to the meeting. For Makie we could also work with Layouts, Geographical plots (maps), Themes etc., for Plots we could push out v. 1.0, rework legends, or create recipes for statistical model objects in StatsPlots. There are also people who’ve announced they’d like to work on VegaLite or PGFPlotsX, and in general it would be relevant to work on any plotting packages in Julia, and allow cross-inspiration.

We will meet in Berlin, which is centrally located in Europe, at the Technical University, which has kindly given us the use of a seminar room for the meeting. The meeting will be open to everyone. We plan to start the days/sessions with a guided-tour-for-contributors on the key packages, to ease entry for interested coders that are first-time-contributors to these packages. Then we’ll split into groups to work, some to agree on designs and open issues, some to code away and close issues. In the evenings we’ll go out and eat together - during the VizCon last year we had a wonderful atmosphere of companionship and achievement in the evenings.

JuliaPlots has a project on the VizCon Vizcon 2 · GitHub , and we suggest creating “VizCon” labels on the various packages to discuss issues to focus on during the meeting. There’s also a dedicated #vizcon2 channel on Slack to discuss issues and ideas for the meeting.

The event has generously received sponsoring by NumFocus. These money will go to keeping the cost of attending (transport, meals, perhaps accomodation) low for attendees, making everybody able to attend. Most of the money will go to helping bringing people to Berlin - as bringing people together is the key. In practice this will take the form of travel grants that all attendees can apply for.

To sign up, please send an email to vizcon@protonmail.com . Registration will remain open, but registrations before the 5th of February are eligible for applying for a travel grant. We will also try to decrease costs for attendees (and improve fun) by coordinating booking some big airbn’b’s for groups of people to share for those who signed up before 5th of February.

To apply for a travel grant, send an email to vizcon@protonmail.com before 5th of February, with the following information: Name and github handle, an estimate of travel cost (e.g. from momondo), means of transportation, student/unemployed/employed, and a note on whether attendance would require getting 50% or 100% covered (or you’d be attending anyway). Priority will be given to people without alternative means of funding (e.g. students with no other income) and prolific contributors to the ecosystem. People using ground transport will be prioritized over air transport if at all feasible (e.g. within 12 hours on the ground) to reduce CO2 emissions (we can probably only subsidise 1 or two long flights in total anyway, due to cost).

16 people signaled that they would be able to attend these days when we planned the meeting, and 15 more have joined the Slack channel, so we expect a great turnout. Come make VizCon THE julia event outside JuliaCon!

  • the VizCon Organizing Team

vizcon
vizcon2731×2731 1.02 MB

(poster credit to @cormullion :heart:)

35 Likes
2

Sadly I won’t be able to make it again this year :(. I hope one year I’ll be able to make it though and looking forward to what seeing what comes out of this year’s edition!

1 Like
3

Allowing remote participation is more effective in reducing CO2 emissions:
https://twitter.com/milankloewer/status/1204383697165856768
Have you considered that?

3 Likes
4

Yes, we’re looking at what we can do to allow remote participation as well :+1:

3 Likes
5

This is a valid point, but asynchronous, distributed remote participation is already the default mode of collaboration for most projects (on Github etc).

Sometimes meeting in person can be a useful complement to this, resulting in new ideas or major changes that otherwise would happen rather slowly.

7 Likes
6

Yes, this is exactly the point of the meeting! :100: Coming together in the same room is the magic. Last year we experienced how massively productive it’s possible to be when you’re actually sitting together with the code.

BUT what we envision is people who are somehow prevented from attending (like Kevin and Vijay who have to look after their babies) can hook on to the momentum being created and support it from afar. It’s a very different thing from actually being there, but increases the total impact of the meeting.

Could we discuss things related to the content here, so that this thread becomes a resource for those wishing to attend the meeting - and maybe take more ephemeral or tangential discussions on the slack (where exactly this was actually already being discussed)?

7 Likes
7

I think I know the benefits of physical meetings.

My suggestion was to make it easy to participate for people who wouldn’t otherwise be able to get there. Work on GitHub tends to be a slow, text-only interaction. Also a videoconference with some of the more interested people is a good improvement over that.

3 Likes
8

I probably won’t be able to make it, have a scheduling conflict … :frowning:

9

I am not able to attend (I wish!) but I would like to mention that I would be extremely happy to collaborate to anyone who would like to work on Julia bindings for Bokeh (I am a Bokeh core dev).

8 Likes
10

I won’t be able to come (even though I might actually be in Germany during those days) :frowning: But if anyone is interested in working on VegaLite.jl related stuff, please be in touch, I’d be happy to discuss/help in the time before the meeting, and maybe I might even be able to join remote for some time.

3 Likes
11

Awesome :+1: - @mcmcgrath13 expressed an interest in doing something for VegaLite

12

I’m trying to figure out logistics and passport viability (shamefully, my passport is closer to expiration than it should be), but I would definitely be down to push forward a VegaLite project if I’m able to swing it.

2 Likes
13

The logistics aren’t going to pan out for this year, but I’d like to participate remotely as much as I can. @davidanthoff what were you thinking for a VegaLite project for this?

14

I think both Integrate with recipe system · Issue #266 · queryverse/VegaLite.jl · GitHub and Create a QuickVega.jl package · Issue #265 · queryverse/VegaLite.jl · GitHub would be good. They are relatively self-contained and add a lot of value. I also think one could make a lot of progress quickly, i.e. there are a lot of (hopefully) low hanging fruits there. I think in terms of a collaborative project the integration with the recipe system would probably really benefit from having folks from the Plots.jl/Makie.jl side in the room.

I think if someone wants to work on either of these, I would try to finish Separating the specs to a different package · Issue #196 · queryverse/VegaLite.jl · GitHub before VizCon.

I went through the other issues, and many of them are fiddly, annoying stuff that I think would be largely frustrating to work on, quite honestly. Many of them are tricky corner cases, where a solution is far from obvious. For some of them I have a strategy in my head, but all of that would require a lot of coordination with me, so I think those issues wouldn’t make good candidates for VizCon.

1 Like
15

After looking at Plot Recipes, that seems very achievable and would benefit from the collaboration. Want to go ahead and assign 266 to me?

1 Like
16

Yes, awesome! One thing that is entirely not clear to me right now is this: would we be creating a vega/vega-lite backend for Plots.jl, or would we be just hooking into the recipe system, without integration with the broader Plots.jl ecosystem?

For all the others here: what approach is Makie.jl taking on that question?

17

As of now, we’re planning for Makie to be able to consume the structure that RecipesBase outputs (a Vector{RecipeData}, I believe) and create a Makie plot from that. I think @sdanisch should have a prototype of that by Vizcon.

18

Ah, cool, I think that would then probably also be the model we would try to follow for VegaLite.jl? Is there a repo where @sdanisch is working on that?

1 Like
19

Hey everyone, remember the deadlines are today :slight_smile:

20

I think Simon is on holiday.
Just to state I don’t think it’ll be that trivial, as there are multiple types of recipes that work at multiple stages of the process. The solution would be very similar to building a backend to Plots, just with a different aim. What a backend does is to parse a recipe into a list of keyword arguments for a Plots call, then translate that into a full specification of a Plots call (by filling out defaults, calculating axes, defining colors etc), then translate all of that into a Dict of keyword args, that can be passed as a plot call to the package doing the actual plotting.

What should be done here is similar, except for the filling out of defaults, which then begs the question of whether the recipes rely on these defaults to be filled out.

My assumption is that the recipe consumption for Makie will take up all the work of several people for the duration of the Vizcon. Depending what we have when we start.