Any plan for further improvement and development

[Fred-Wu]

There have been no activity in the past 6 months, just would like to check any future plan for vscode-R?

I guess it is mature to some extend, and I have been using it in daily basis in the past 2 years.

It would be a pity if it ends like this.

[benz0li]

@renkun-ken I hope this project continues despite of Posit's Positron, which is derived from Code - OSS and uses its own Jupyter R Kernel.

This is important for users of both code-server and GitHub Codespaces, e.g. the

• JupyterLab docker stack and
• Data Science dev containers

which are not only available for R and Python but also for Mojo and Julia.

[mihaiconstantin]

I also hope this extension continues to be developed. What you guys have achieved with it is remarkable, and it has become an integral part of my and my colleagues' R workflow. Thank you for for all your hard work so far!

[renkun-ken]

Thank you all for your support and kind words about the project. I’m glad to hear it has been valuable to your workflows. I apologize for the recent inactivity; I've been quite busy with work in the past few months. I agree that it's important to keep the project going and am considering finding more contributors to help with its development and maintenance. Your continued interest and any assistance you can offer would be greatly appreciated :)

[werkstattcodes]

If Microsoft wants to keep some of the R users on vs code (and not see them eventually all migrating to positron) they should sponsor your excellent work.

[benz0li]

As advocates of open-source software (OSS), we sponsor

• the QGIS project,
• the Julia language,
• the R Foundation and
• the FreeBSD Foundation.

@b-data is happy to add this project to the list. @renkun-ken Please let me know how this can best be accomplished.

Unfortunately, open source projects [without a business plan] rarely receive the necessary (financial) support.

[albertosantini]

I second the comment it would be a pity not to support a so valuable extension.
In my workflow it is almost feature complete.

Firstly, why I don't use RStudio (or Positron tomorrow).
I am a programmer and the editor is my main tool: in the last years I choose VSCode (after 20+ of Vim), a good tradeoff between the Vim modal editing and an IDE, and I don't want to use different editors for different programming scenarios.
I would prefer considering Emacs+ESS (waiting for 30.x release) instead of Positron, leaving VSCode.

Of course your mileage may vary.

Secondly, I don't think a financial support may resolve any issue with the project, even if it would help; generally speaking it is the lack of time the main cause of a reduced activity. Sure, maybe you find funds for a FTE, but to maintain a project you need more than a FTE, changing an issue with another one, finding funds. I don't know when creating an important and concrete extension, like vscode-R, you intended to develop a sort of business. The main driver is the passion and the will to resolve a need you have together with other people.

A roadmap with intents and goals is a starting point for finding more contributors.

Just a high-level list.

• Weekly issues triage: labeling or classifying the issues; even if it seems to me the status is quite healthy.
• Yearly create a features poll to address the main development, tracked by a dedicated Project.
  • I vote for a Data Explorer review. :)
• Semestral goals (April and October, major releases): just to give a pace to the project.

A sideline idea.
Any possible collaboration with Positron?

From Positron FAQs:

Why build a new IDE rather than VS Code extensions?
Our aspirations for Positron go far beyond what is possible via only extensions. Ultimately, VS Code’s Extension API doesn’t provide enough leverage to modify the main “workbench” surface.
To deliver a truly excellent data science experience, we need to change and augment core components and UI elements that are outside the scope of VS Code’s extension API.
We have developed some components as extensions for use in both Positron and VS Code, such as Quarto and Shiny for R/Python. However, given the additional API surface in Positron, we plan to progressively enhance these and future extensions when installed in Positron.

Fair enough, but like Vim e Neovim, maybe there is a sort of shared components, where the enhanced part is active in Positron, but the "mininal" one is usable also in vscode-R. In this way vscode-R gets an advantage by the product capacity of a company and Positron gets an advantage in terms of marketing, about brand awareness.

[albertosantini]

Just to give an idea about the tasks the contributors need to afford.

Issues (reading, triaging, labelling, assigning)

Starting point at time of writing (2024-dec-11):

• 162 Issues (2018-2024)
• 882 Issues closed (very well done)
• 15 Pull requests
• 457 Pull requests closed (good job)

With the following labels:

• 86 bug
• 48 feature-request
• 05 engineering
• 23 other

Main barriers for a contributor (very time consuming):

• different operating systems (Linux/Windows/MacOS)
• different configurations (R versions, settings, with or without radian, browsers, remote, etc.)

Generally speaking, if a contributor uses an OS, unlikely they will install a VM to reproduce the same setup of an issue. Also a different configuration is a friction to the support. I know I am very lazy. This is just to say the contributors need to be distributed in terms of OS and configurations.

When an issue is created, it should include a Minimal Working Example (MWE) or the minimal steps to reproduce it, mitigating the development barrier. Often, non intentionally, this is not done, but this "problem" is common to the open-source and closed (internal) projects. So just a personal rant. :)

Development

Great resource, the wiki. In this case https://github.com/REditorSupport/vscode-R/wiki/Contributing

• Maintenance
  • Issue workflow (from bugs or fast feature requests)
• Feature request
  • Product polls
• Architecture
  • Chore activity
  • Refactoring
  • Optimization and performance

Metodology (metaphor of a airport)

Please, not a formal one, just to share a mental model or to say we are on the same page.

• Create a (GitHub) Project
  • Arrivals: maintenance issues (short-term delivery)
  • Departures: products or issues (medium-term delivery)
  • On Radar: architecture and product activity, not yet in departures
  • In The Hangar: chore, refactoring or new approaches taken in consideration

Conclusions

Hope that helps to clear the personal thoughts of some (new and past) contributors.
Of course, here the opinion of actual maintainers is very important and "final".

[albertosantini]

I suggest to pin the issue, if you are agree.