Roadmap for the Project, and new Maintainer for the Plugin

[joshuataylor]

Introduction

Hi All,

The IntelliJ Elixir plugin was started a decade ago by @KronicDeth, and it is a fantastic plugin with 1.8k stars on Github, 439k downloads through the JetBrains Plugin Marketplace.

The contributors have invested tremendous time, energy, and effort into creating an open-source plugin, written in Java/Kotlin, for a community primarily working in Elixir.

Unfortunately, life events happens, and opensource work is usually the last thing on the list of things that the maintainer will want to work on - I know this from personal experience where life gets really busy.

I contacted @KronicDeth , and am pleased to announce I have been added as a co-maintainer for this repository, and am excited to help contribute to the project's ongoing development.

I have been using Elixir for many years, and this plugin to write all of it :-).

What this means

Honestly, not much will change for users of the plugin, other than more frequent updates.

I just really wanted to note that there will be no change to the license, Code of Conduct, etc.

1. All sponsorships, donations, etc will go to @KronicDeth as usual.
2. License is still Apache License
3. Hopefully more frequent code updates/reviews, which will foster more collaboration - not all issues are Java/Kotlin - it's also figuring out Erlang/Elixir issues :).
4. Add GitHub Discussions, which will help with questions.

Roadmap

I would like to propose a roadmap going forward, ordered by importance.

Phase 1: 2024 support

(DONE!)

1. Update to support 2024.xx supported IDEs, see #3569
2. Review any open Pull Requests

Phase 2: Update build environment

Ensure we've got a "modern" build/test/CI environment, which will help going forward.

This will hopefully make it easier and more transparent for new and existing contributors.

Phase 2 Meta Issue

Phase 3: Fix issues with new Elixir/Java Versions

As there have been a huge amount of changes made to both IntelliJ, Erlang and Elixir, we need to ensure we can accomodate these changes, whilst still maintaining backwards compatibility.

JetBrains Changes

To do this, a list will be created from the Issues for bugs that occur due to IntelliJ, Erlang or Elixir version changes, example #3362.

Community involvement at this phase would be amazing, as there will be a slew of Java/Kotlin and Erlang/Elixir issues to diagnose and fix! Ever wanted to know how an IntelliJ Plugin is made? This would be a great chance to learn and contribute.

Phase 3 Meta Issue

Phase 4: Clear backlog

After Phase 3, if we're still sane, it'll be a good idea to clear out the backlog.

I would also like to implement a better way to report logs without having to make an issue through GitHub.

JetBrains supports this, but we'll need to have a privacy-focused way to treat this, but this would be completely option, the the user must also click that button to report.

Phase 4 Meta Issue

Notes

JetBrains APIs

JetBrains APIs move quite fast, especially with major releases (eg 2023.xx -> 2024.xx). 2024 Incompatible Changes, for example shows how many changes have been made for 2024.

One on hand, yes this is good, as it allows them to add new features and provide a good experience.

On the other hand, this is tedious for plugin developers when things break, as sometimes there are major problems.

Going forward, testing using the EAP versions will be done on CI to ensure that everything works as expected.

Feedback / Suggestions / Ideas

Please add any feedback, suggestions, ideas to this thread - the idea is to be as transparent and open as possible.

[ghenry]

Can JetBrains not help sponsor this? Or the Erlang Foundation?

How can we help?

[joshuataylor]

To be completely honest, my current (and future, at this stage) financial situation and personal life allows me the privilege to work on this plugin and other opensource work.

Once we fix the 2024.x issue and start creating a roadmap of issues, a great help by the community would be:

1. Working on and fixing issues caused by newer versions of Java/Kotlin/Erlang/Elixir
2. Reporting/triaging issues

From a sponsorship point of view, I'd rather leave that out for now - perhaps we can reach out for a grant for resources such as CI/CD hosting on a cheap provider like Hetzner etc to improve build times.

I'm also not an expert in Java/Kotlin, and would love any feedback for new PRs from the community as well.

[iampeter]

Again, thank you @joshuataylor for getting involved and for pushing the first updates. As for the roadmap, is broader support for Heex on the horizon?

[chuggingCoffee]

I'm still getting into Elixir, but have already really enjoyed this plugin. Thanks for pushing this forward @joshuataylor, and thanks for all the long-term work on this @KronicDeth 👍

[gaggle]

Just fabulous news. Really echoing the ideas and energy of finding ways for us to support the efforts here. I don't know Java/Kotlin but would love to find ways of supporting, and if I'm not alone on that I want to gently ask you @joshuataylor if you would consider investments into kinda "office hour" threads in GitHub, or Elixir Forum, or somewhere that aims to cover details of the plugin?

I mean: Instead of you writing code, it would be you telling the rest of us about how the plugin works and where we should focus our efforts. I think it's possible I could be skilled up in Java/Kotlin just enough to start contributing towards the more simple improvements, but I need some initial help as I'm otherwise just staring at the code. Maybe there are some architecture sketches to show and discuss? Maybe a topic of "how to get started contributing" could be in order? And other kind of grassroots-enabling topics like that. E.g. a GitHub Discussions thread or ElixirForum thread or something where you bring up how to get started, and then we all just kinda try it out together and we get to ask all our stupid questions, etc.?

I'm not suggesting this to take you or anyone's energy away from the code-work that is probably what most of us assume will happen when you post about becoming a co-contributor, but I think this other angle is also worth considering to try and capture more community engagement.

[joshuataylor]

Yeah, I'm super keen to make it as easy as possible for people to contribute, and with the recent improvements from JetBrains around developer experience should make this a lot easier. We'e probably not Java/Kotlin developers, but Elixir developers :-).

I believe adding discussions to this repo would be good for questions around contributing, plugin questions etc, and I would love to do an office hours, let's get that started.

I honestly believe adding a feature, fixing a bug should be a really straight forward process, you can use the IntelliJ Community Edition for this. Make it as easy as possible.

I'm also still learning about the plugin architecture, but will definitely create a broad overview of this, and links back to the JetBrains documentation about that feature.

I also want to extend out the CONTRIBUTING.MD with all of this as well!

[yordis]

Second to that,

At some point, I tried my best to contribute #2578. Ultimately, I had to blindly add code that I couldn't run nor understand how, primarily because of getting the devtools working and the lack of processes around it.

So, from first-hand experience, I think anything you can do to document and unblock folks who are capable of figuring out Java but do not know enough about the Java ecosystem or how to get to a point where we can put a breakpoint will pay off.

[marcdel]

This is a roadmap-ish question: I'm trying to understand which things are hard/impossible with the plugin API and parser/lexer vs. just haven't been prioritized. Does anyone have a feel for whether things like the extract/inline refactorings are possible here?