Add community calendar, GeoJupyter announcement blog post, update about page

[mfisher87]

Goal: Define GeoJupyter, what we're doing / have done, where we're going, and how to participate. After reading this, someone in the GIS community who hasn't heard of GeoJupyter will have an understanding of what we're trying to do and if they want to contribute, how to get started. Attendees of our first core community meeting should feel comfortable going in to the meeting after reading this blog post.

Re-using language from the job posting: https://dse.berkeley.edu/about/jobs/scientific-software-developer

Preview: https://geojupyter--6.org.readthedocs.build/en/6/blog/20250108-introducing-geojupyter/

[mfisher87]

🔮 ? :)

[weiji14]

For the vision, maybe we can use the term 'multi-player mode' to differentiate JupyterGIS from the classical single-player desktop GIS apps? E.g. I'm keeping an eye on the Zed code editor which had a vision of designing a code editor from the ground-up based on collaborative editing (see their intro blog post at https://zed.dev/blog/beta), and there are parallels to what GeoJupyter is trying to do here.

[mfisher87]

Really trying to keep this a quick read while still hitting the key points.

[mfisher87]

Too dorky? 😆

[mfisher87]

Reopened to trigger RTD automations

[iamciera]

Hi Matt, Amazing work.

Love the the Process section - shows clear identifiable steps forward! And highlighting some early takeaways from the interviews! This will lead nicely into a blog post that goes deeper into the take-aways from the interview process.

Few minor nit-picky comments, you can take or leave:

• "programming-based GIS world which provides cutting-edge editing, reproducibility, and publishing experiences." Not sure what you mean by publishing experiences, but I believe pro-ArcGIS users would argue that the ArcGIS Storymaps are a great publishing experience. Or, I think I see, are you talking about automated publishing pipelines, like continuous integration and delivery? Maybe just add "automated publishing experiences". Or ignore this comment completely 😂
• I would stick to using one of these phrases "code-based" or "programming-based", not both.

[mfisher87]

"programming-based GIS world which provides cutting-edge editing, reproducibility, and publishing experiences." Not sure what you mean by publishing experiences, but I believe pro-ArcGIS users would argue that the ArcGIS Storymaps are a great publishing experience. Or, I think I see, are you talking about automated publishing pipelines, like continuous integration and delivery? Maybe just add "automated publishing experiences". Or ignore this comment completely 😂

Thanks for this, that's a great point! Yes, I'm largely thinking of continuous delivery automation, a little bit about things like Zenodo, or of the many tools that take a notebook as an input and produce a website as an output! I like "automated publishing experiences" :)

I would stick to using one of these phrases "code-based" or "programming-based", not both.

💯 Great catch. I was jumping between the two mentally because I couldn't decide which I preferred. I think I prefer programming-based, but I'm struggling to verbalize why.

[fperez]

Very minor changes suggested, otherwise fantastic work, thanks @mfisher87 !!

[weiji14]

For the vision, maybe we can use the term 'multi-player mode' to differentiate JupyterGIS from the classical single-player desktop GIS apps? E.g. I'm keeping an eye on the Zed code editor which had a vision of designing a code editor from the ground-up based on collaborative editing (see their intro blog post at https://zed.dev/blog/beta), and there are parallels to what GeoJupyter is trying to do here.

[mfisher87]

For the vision, maybe we can use the term 'multi-player mode' to differentiate JupyterGIS from the classical single-player desktop GIS apps

Nice, I like that! Thank you :)

Applied requested changes!

[mfisher87]

Thanks everyone for your input!! We can always make more changes. If anyone notices anything open an issue or let me know!