Goal ideas

[jcbhmr]

• Define guidelines of what is and isn't a "community devcontainer $X" (feature, image, template, etc.)
• Expand upon the general principals of popular, general, and easy-to-use stuff from the official devcontainers org's projects
• Have a /features repo
• Have a /images repo?
• Have a /templates repo?
• Have a /awesome-devcontainers repo?
• Incorporate things from many facets of existing devcontainers features from other users to bring them under a community umbrella (see below)

Q: Why centralize everything into one organization? Why do that vs username/devcontainer-features for everyone's custom features? Why would I want to use the devcontainers-community one?
A: That way if you decide to move on (to another cool technology like investigating machine learning, writing Python full-time, or you get employed at Google or something) someone else doesn't need to bug you to merge changes since it's handled by the organization. Other than that, not much different, no.

The goal I guess is to kinda be like https://github.com/vercel-community which has (I think) curated community runtimes.

This project "devcontainers-community" is, I think, what I was trying to push devcontainers-contrib to be, but that didn't really pan out.

As for the specific well-documented criteria of "what makes a feature a feature" and "when does something go from postCreateCommand to feature" those are things that need to be ironed out and would help the direction of this project. Previous discussion in devcontainers-contrib/.github#4 and devcontainers-contrib/.github#5 and there was a whole Discussions tab in https://github.com/devcontainers-contrib/features but that seems to have been removed 😢

[jcbhmr]

@eitsupi are you interested at all in this project? I know that I literally just created this org today, but I'd be interested in a second opinion. You seem to be interested in consolidating features, templates devcontainers-contrib/templates#4, etc. into a community editable organization to avoid the bus factor (or the less extreme "lost interest factor") problem. Particularly for popular ones like Haskell, Deno, Emscripten, etc. that aren't quite popular enough to get into the official list.

Who knows, if this is a bad idea or there's a better way to consolidate features like this, or its too hard or whatever this org might be get deleted. 🤷‍♂️ So far it's just an idea.

[jcbhmr]

/re @eitsupi Would it be worth putting devcontainer features repos under each "parent" organization instead? So like for Deno, having https://github.com/denoland/devcontainer-features or similar? This would be a lot of work since you'd need to, in essence, get the maintainers of a particular org to take on more responsibility... I don't know. Maybe?

Then again, if we look at https://webinstall.dev/ which does something similar ish in their stuff, they do a central repo https://github.com/webinstall/webi-installers/tree/main

And if we look at other things like https://github.com/orgs/asdf-community/repositories and even the current https://github.com/devcontainers/features it seems like there's a trend to managing things yourself.

So... yeah I defeated my own idea.

[eitsupi]

Thank you for inviting me to join this organization.
However, I really fear that I will have unlimited responsibilities. So I cannot take on a maintainer of Feature distribute repo unless the scope of the organization is clear.
Also, if we were to narrow the scope considerably, I question whether we could justify devcontainers-community as the organization's name.

As for defining what qualifies as a feature, I initially tried to stem the "oh and pls add this pip install X feature" in devcontainers-contrib, and I think that ship has already sailed. There was some brief discussion in devcontainers-contrib/.github#4

One hint, I think, is that the jupyter Feature that was present in https://github.com/microsoft/vscode-dev-containers/blob/5a084a93b0736ea86395ac99019a5b72a00b6341/script-library/jupyterlab-debian.sh has been removed in devcontainers/feature, and the installJupytelab option in ghcr.io/devcontainers/features/python (https://github.com/devcontainers/features/blob/1449f416a0d5c65fbd7e7bfac041eb43f1ecd98d/src/python/devcontainer-feature.json#L39-L43) is also being considered for removal in the future (See devcontainers/features#187 (comment)).
(devcontainers/features#67)
Also check the discussion about separating the ability to install apt packages from common-utils devcontainers/features#67.

I basically want to follow the discussions and policies at the devcontainers org.

Would it be worth putting devcontainer features repos under each "parent" organization instead? So like for Deno, having denoland/devcontainer-features or similar? This would be a lot of work since you'd need to, in essence, get the maintainers of a particular org to take on more responsibility... I don't know. Maybe?

I totally think it is better that way.
So I supported the creation of https://github.com/mamba-org/devcontainer-features and https://github.com/JuliaLang/devcontainer-features.

And so if the parent organization of the Dev Container Feature I manage is willing to distribute the Dev Container Feature, I will transfer it.
See eitsupi/devcontainer-features#59.
(I really did not want to own the Julia Feature, but I could not think of any repository that would have the rights to it at first, so I had no choice but to put it in my repository.)

---

One idea is to list the maintainers in the README as was done in microsoft/vscode-dev-containers.
Like https://github.com/microsoft/vscode-dev-containers/blob/5a084a93b0736ea86395ac99019a5b72a00b6341/containers/r/README.md?plain=1#L11

[jcbhmr]

/re @eitsupi

Thank you for inviting me to join this organization.
However, I really fear that I will have unlimited responsibilities. So I cannot take on a maintainer of Feature distribute repo unless the scope of the organization is clear.

Sounds good! 👍 I think I invited you more so as a "hey please keep me accountable" and "hey what's you thoughts on this idea? Is there a better way?" than as a person I expect to write 1000s of lines of code.

I don't really expect anything major to happen with this org yet; I want to take it nice and cautious. Who knows, if the idea to put everything into <language-or-tool-organization>/features happens, this org could be moot and get deleted! 🗑️

---

One hint, I think, is that the jupyter Feature that was present in https://github.com/microsoft/vscode-dev-containers/blob/5a084a93b0736ea86395ac99019a5b72a00b6341/script-library/jupyterlab-debian.sh has been removed in devcontainers/feature, and the installJupytelab option in ghcr.io/devcontainers/features/python (https://github.com/devcontainers/features/blob/1449f416a0d5c65fbd7e7bfac041eb43f1ecd98d/src/python/devcontainer-feature.json#L39-L43) is also being considered for removal in the future (See devcontainers/features#187 (comment)).
(devcontainers/features#67)

Also check the discussion about separating the ability to install apt packages from common-utils devcontainers/features#67.

I basically want to follow the discussions and policies at the devcontainers org.

This seems like a good sentiment to take. I think this is a good direction.

I totally think it is better that way.
So I supported the creation of https://github.com/mamba-org/devcontainer-features and https://github.com/JuliaLang/devcontainer-features.

That's awesome! Thanks for doing that! ❤

One idea is to list the maintainers in the README as was done in microsoft/vscode-dev-containers.
Like https://github.com/microsoft/vscode-dev-containers/blob/5a084a93b0736ea86395ac99019a5b72a00b6341/containers/r/README.md?plain=1#L11

This seems like a good idea.

Sidenote: What was the history of the microsoft/vscode-dev-containers repo? I am uninformed of any developments with devcontainers since about Nov/Dec of 2022 when I started really using GitHub Codespaces for personal use and at my University where we started using Codespaces for compsci assignments. It's been going great, and I've just been looking for more prominent? defacto? official-ish? whatever the word is - looking for more languages, tools, features, images, templates, etc. like Emscripten, Deno, Haskell, etc. that aren't in the official list. That and that they are actually updated.

---

As for a more "next steps" or concrete plan with this organization @devcontainers-community, I think I have a rough idea that I'll post in a top-level comment (not a reply to this one) in this https://github.com/orgs/devcontainers-community/discussions/1 discussion. Or maybe it'll be another separate discussion. Who knows! I have yet to write down my thoughts/ideas. I'll /cc ping you to keep you informed.

Thanks for being a voice of reason. I appreciate these discussions very much. 🙏

[jcbhmr]

Thank you for inviting me to join this organization.
However, I really fear that I will have unlimited responsibilities. So I cannot take on a maintainer of Feature distribute repo unless the scope of the organization is clear.
Also, if we were to narrow the scope considerably, I question whether we could justify devcontainers-community as the organization's name.

/re @eitsupi Any other changes/clarifications that I can/should make? I think we got it nailed down to a somewhat reasonable goal of "just start with some templates and maybe some features" in #3, but I wanted to be sure that you're OK with what I've proposed/done. Just to be sure. 😉

[eitsupi]

@jcbhmr Note that Templates and Features have a very different level of maintenance importance.
That is, Templates are only downloaded once, while Features are expected to continue to be downloaded many times in the future.

So maintenance of Features is far more important than maintenance of Templates, and when Features are handled by such an organization, the maintainer needs to be clearly stated, I think.

[jcbhmr]

Other organizations that use the *-community are:

• https://github.com/nuxt-community
• https://github.com/vapor-community
• https://github.com/qiskit-community
• https://github.com/capacitor-community

https://github.com/search?q=community&type=users vs https://github.com/search?q=contrib&type=users

"-community" over "-contrib" because "-community"=31.7k users/orgs, vs "-contrib"=546 users/orgs

[jcbhmr]

Concrete plans

• Step 1: reach out to popular tool organizations to see if they are willing to create a <org>/devcontainer-features or similar repo

Some of the ones that come to mind are:

• Deno https://github.com/denoland https://github.com/denoland/deno/discussions https://containers.dev/features#:~:text=1.0.6-,Deno,-(via%20Github%20Releases (there are two features?)
• Emscripten https://github.com/emscripten-core https://github.com/emscripten-core/emscripten/discussions https://github.com/ebaskoro/devcontainer-features/tree/main/src/emscripten

Deno, in particular, already has its own https://github.com/denoland/setup-deno GitHub Action that is under their official umbrella, so it'd be worth citing that.

Concrete plan of action: @jcbhmr will inquire in a Discussion post https://github.com/denoland/deno/discussions and https://github.com/emscripten-core/emscripten/discussions about the possbility of doing this <org>/devcontainer-features repo for Deno and Emscripten.

Any other organizations?

---

• Step 2: Open a poll, discussion, Q&A whatever thing in this org (@devcontainers-community) to get multiple viewpoints on how to organize community-driven non-official-but-still-kinda-official devcontainer features, images, templates, docs, articles, website, whatever stuff..

If the goal of getting features under the actual organization that maintains the core thing doesn't work, then it'd be nice to have a sort of "clone" of the official https://github.com/devcontainers project for unofficial-but-still-kinda-official features and images and templates and such.

Concrete action: @jcbhmr will open a discussion about this. something along the lines of "layout ideas" or similar in a poll maybe? IDK. AFTER doing step 1 of initial dialogue with the parent orgs.

https://github.com/orgs/devcontainers-community/discussions/2

/cc @eitsupi

[jcbhmr]

I've reached out to denoland/deno#18144 and emscripten-core/emscripten#18944 so we'll see what happens...

In the meantime, I guess I'll get started on some of the other @devcontainers-community things in #2 and in-general

/cc @eitsupi

[eitsupi]

@jcbhmr As I mentioned previously in devcontainers-contrib/templates#4, what do you think about transferring the template from https://github.com/microsoft/vscode-dev-containers to this organization and continuing to maintain it?
(Only with the consent of the original maintainer, of course.)

The template in https://github.com/microsoft/vscode-dev-containers still seems to be downloaded quite a bit but is no longer updated and the content is out of date.
https://github.com/orgs/microsoft/packages?q=vscode-dev-containers&sort_by=downloads_desc&visibility=public

@nathancarter Hi, jupyter-datascience-notebooks seems to be the most downloaded Dev Container Template on https://github.com/microsoft/vscode-dev-containers.
What do you think about transferring this to this organization? (I can help modernize this)

[nathancarter]

I had no idea that it was so often used! But it does not surprise me; data science is huge. I created it basically because I needed it, but I honestly don't have time to regularly update/maintain it, so I would be super grateful if the community wanted to do that. Please see it as 100% community accessible, and you hereby have from me any permission you need to use/maintain/improve/move/share it.

[eitsupi]

Thanks for your reply!

If we move the Template to somewhere (I'm keen on it and have been exploring the possibility for a few months like devcontainers-contrib/templates#4), I think we'll need to get your permission on https://github.com/microsoft/vscode-dev-containers (see microsoft/vscode-dev-containers#1669 and microsoft/vscode-dev-containers#1673) and I'll mention you again in that case.

[jcbhmr]

@jcbhmr As I mentioned previously in devcontainers-contrib/templates#4, what do you think about transferring the template from https://github.com/microsoft/vscode-dev-containers to this organization and continuing to maintain it?
(Only with the consent of the original maintainer, of course.)

I think this is an awesome idea 🤩 and fits perfectly with the purpose of @devcontainers-community! The devcontainers-community/templates repo is a freshly generated copy of devcontainers/template-starter. I think @nathancarter's template would be a great first addition to get off the ground! 🚀

@eitsupi I think that if this is successful in the future (give it a few days/weeks to see what happens) it might also be worth doing as you said in devcontainers-contrib/templates#4 and inviting/reading out to other template individual maintainers.

Wondering if it would be possible to contact each maintainer of the community templates in microsoft/vscode-dev-containers and move it here if they agree.

I know you mentioned above that you've got other projects 💚 so I just want to say I'm willing to do the grunt work for any stuff you need me to do. 👍

[eitsupi]

@eitsupi I think that if this is successful in the future (give it a few days/weeks to see what happens) it might also be worth doing as you said in devcontainers-contrib/templates#4 and inviting/reading out to other template individual maintainers.

Yeah, I agree, https://github.com/microsoft/vscode-dev-containers is already deprecated, but few templates have moved on from there...... (Only devcontainers' templates, R, Swift, I think.)

[eitsupi]

I noticed another thing.

That is that Template has a docker compose file (e.g. https://github.com/microsoft/vscode-dev-containers/tree/main/containers/javascript-node-azurite), which can have a myriad of combinations that can occur.

Perhaps it would be better to separate repositories for Templates that include a compose file.