How should this organization be laid out?

[jcbhmr]

🛑 this discussion is a bit off topic and obsolete. check out #1 and #3 for a more concrete discussion

---

if we were to narrow the scope considerably, I question whether we could justify devcontainers-community as the organization's name.

If this organization is going to live up to its name, that means doing actual things! In this case, making and maintaining features that people want to use, but aren't in the official devcontainers/features list. If one person loses interest, there's another person to pick up and continue. But hey! If this @devcontainers-community organization is redundant, that's awesome! 🚀 So far, I've reached out to @denoland and @emscripten-core about the possibility of adding a devcontainer-features repo under each organization. If I/we do this with more organizations, well, this @devcontainers-community would be superfluous! And that's the goal!

🟢 The goal: make this @devcontainers-community organization redundant because all major language/tool organizations host their own devcontainer features.

But it might not be realistic... There's also undoubtedly other tools like asdf, LaTeX, and probably more where it's way easier to maintain a feature independent of the organization itself. And, some organizations might decline or not want another repo that they need to keep up with. That's totally OK and up to them.

Thus, inevitably, some kind of community @devcontainers -but-with-more-stuff is probably going to spring up. In fact, it kind of did with @devcontainers-contrib, but it still suffers from the single-maintainer bottleneck. I'm hopeful (but cautious) that this @devcontainers-community can be more open and encourage more involvement.

So what should be done with this org?

I don't know... 🤷‍♂️ That's what this discussion is about! What repositories should be created? What features? What images? If any? Should this organization be deleted? Put on hold? Restricted scope? Wide scope?

I/we don't have to answer these right away; this is just an update on what @jcbhmr is thinking about right now.

[jcbhmr]

Some 🧠 brainstorming ideas:

• It could be segmented so that there's different "sectors" of features, like:
  • devcontainers-community/language-features
  • devcontainers-community/meta-features -- things like "first-run-notice" or others?
  • devcontainers-community/tooling-features
  • devcontainers-community/npm-features
  • devcontainers-community/language-images
  • devcontainers-community/
• It could be an almost duplicate mirror of the official devcontaineres org with
  • features
  • images
  • templates
• Something else?

[jcbhmr]

What makes a feature?

I don't know exactly how to quantify my thoughts on this but here's some examples that I have:

Features:

• node (includes npm)
• emsdk
• cmake
• xmake
• julia
• ruby
• gh (github cli) -- could be installed via homebrew, but it's such a widely used tool that it deserves a feature. It's something that is more of an "implicit global tool" than a "remember to install this obscure CLI app that this script uses"

Some things that are not features:

• bikeshed - should be in dep manifest OR install in postCreateCommand
• prettier - should be in package.json OR install in postCreateCommand
• nektos/act - install in postCreateCommand since it's so easy: gh extension install nektos/gh-act (GitHub CLI)

open to discussion on this

[jcbhmr]

This is kinda turning into what should have been a discussion in a /features repo