Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State of CIDER survey? #3697

Open
alexander-yakushev opened this issue Jun 2, 2024 · 8 comments
Open

State of CIDER survey? #3697

alexander-yakushev opened this issue Jun 2, 2024 · 8 comments

Comments

@alexander-yakushev
Copy link
Member

alexander-yakushev commented Jun 2, 2024

I had an idea sometime ago to conduct a [yearly?] survey for CIDER users, similar to State of Clojure. Such survey would have multiple goals:

  • Engage the community (people love this kind of stuff)
  • Inform users about new features (we can have a section dedicated to figuring out if people know/use/love each significant feature of CIDER). Having such a list together with links to the docs is another chance to tell about the features.
  • Discover which features are underused. In the same vein, there are some pretty obscure features in CIDER like tracer, profiler, etc., all backed by some third-party abandonware. If those features are not used much, we then can make major changes to them (rewrites, migrations to other tools, etc.) without worrying about incompatibilities too much.
  • Have our own statistic regarding used Clojure versions, JVM versions, etc. in addition to State of Clojure data.

What do you think?

@vemv
Copy link
Member

vemv commented Jun 2, 2024

If you feel it would help you with misc goals, why not 👍

I sense that we don't have at the moment as much traction as we once did, so perhaps of a yearly format it could be a rolling format - we can invite people to fill a form anytime and link to it in releases, announcements, the issue template, etc.

In the same vein, there are some pretty obscure features in CIDER like tracer, profiler, etc., all backed by some third-party abandonware.

Quick note about this, perhaps for future developments we could try a more modular approach.

https://github.com/flow-storm/cider-storm and https://github.com/magnars/kaocha-runner.el are modern examples of stuff built on top of CIDER.

That way we keep the project lean and it becomes very easy for everyone to see which features are used, maintained, etc.

I don't have a strong preference, for instance https://github.com/clojure-emacs/logjam / cider-log-mode could have as well been built completely outside of cider. But then again it benefited from our templates, CI, reviews, and bugfixes.

A middle ground is keeping such contributions under the clojure-emacs umbrella.

@bbatsov
Copy link
Member

bbatsov commented Jun 2, 2024 via email

@alexander-yakushev
Copy link
Member Author

Right, I should have consulted with Google before asking. This is great, we can use the questions from there as a baseline. What do you think of using Surveymonkey this time? I find it fun to go over results for SoClj surveys and see all the results and charts, it would be so for CIDER survey too.

@bbatsov
Copy link
Member

bbatsov commented Jun 2, 2024 via email

@alexander-yakushev
Copy link
Member Author

Right, it is limited in number of questions (and probably number of respondents) in its free plan. I'll scan for alternatives.

@bbatsov
Copy link
Member

bbatsov commented Jun 2, 2024 via email

@bbatsov
Copy link
Member

bbatsov commented Jun 2, 2024

Discover which features are underused. In the same vein, there are some pretty obscure features in CIDER like tracer, profiler, etc., all backed by some third-party abandonware. If those features are not used much, we then can make major changes to them (rewrites, migrations to other tools, etc.) without worrying about incompatibilities too much.

Yeah, that's fair. CIDER accumulated many features over the years and not all of them gained traction - even I forget some features from time to time. 😆 For a while I was trying to move what seemed like useful 3rd-party functionality to CIDER, but at some point (e.g CIDER 2.0) we can remove/extract some features back to extensions. Would be good to know what the users actually use/value.

That way we keep the project lean and it becomes very easy for everyone to see which features are used, maintained, etc.

In theory that's true, but in practice it requires more time when you have to do coordinated updates between several projects. Many features that were originally external (e.g. the profiler and the inspector) were abandoned by their original authors and with their consent I opted to bring them to the core at some point, as for me it was easier to have less Emacs and middleware packages. Every approach comes with trade-offs and I usually optimized for my limited time. :-) But obviously there's a limit to what a single person can do on the side and I didn't pay much attention to features I don't use myself. From experience I can tell you that having an Emacs package + separate middleware package + separate underlying library wasn't fun either (e.g. cider-profiler + nrepl-profiler + clj-profiler).

@alexander-yakushev
Copy link
Member Author

If it’s not expensive and we plan to use it long-term, we can also pay for it from OpenCollective.

That's fair; but the price is kinda steep to be paid monthly for something we'll need once a year at best. I don't think it's useful to do it more often.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants