Change list title about awesome-docker HOT 13 CLOSED

So far the ideas are:

• keep the name awesome-docker
• extend the current list with labels, categories, etc.
• create a new list
• split into sub-lists
• create a family of list e.g. awesome-containers-<sublist>, where <sublist> can be empty, docker, orchestration.
• include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes, Unikernels etc..)

What are the concerns?

• amount of work: we might overwhelm ourselves with the sheer amount of tools and pace the community is evolving
• Overlap with awesome-kubernetes, and https://landscape.cncf.io/

from awesome-docker.

I like the idea to be more open and not only focused on docker. @dmitrytokarev create another with the initial content of »awesome-docker«? There are already some »awesome-container« on GitHub. Pro for renaming this list is, it redirects everyone from an old bookmark to the new repository. There might be a short sentence of the history of this awesome list at the top.

from awesome-docker.

Hi all,

I have been thinking about this and I align with @veggiemonk The awesome-dockerlist is very popular and reference everywhere from official Docker documentation to Kubernetes projects.

My vote is to extend the current list with labels, categories, etc. Additionally, creating a new list parralel to awesome-dockerwould be great. We should make sure it is generic enough to cover all use cases in the future i.e. serverless, unikernel, etc that somehow fall under containers as well. Much like the CNCF projects we should set criteria/certain functionlity which admits projects to the repo or not like must utilize containers or something similar.

My braindump. I am open for suggestions.

from awesome-docker.

I would keep awesome-docker. I think that docker has evolved from a product to an API/ecosystem and we should include things like OCI, containerd and anything else that is docker compatible e.g. (vSphere integrated containers).

We can also include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes,Unikernels etc..) so that visitors who come looking for something else at least have a good navigation point.

Extending the scope to include orchestration I think would be too overwhelming - maybe we should just more prominently display the link to https://github.com/ramitsurana/awesome-kubernetes ?

from awesome-docker.

Well then the repo will need to be renamed. IMHO it's better to create another list: awesome-containers?
Optionally can have some sort of sub-list dedicated to OCI.

from awesome-docker.

Incoming braindump....

• I would keep awesome-docker. That doesn't imply to keep the content here, though. We could split the list into bigger "sub-lists", if need be, and awesome-docker would only be an overview of those sub-lists or categories.
• Maybe we could create a family of lists using a naming pattern, e.g. awesome-containers-<sublist>, where <sublist> can be empty, docker, orchestration.
• Is Docker a sub-category of containers? We should always try to think like our consumers: are they searching for Docker or containers? I suppose that most people think and write Docker, but mean containers. If we assume that most people use Docker as synonym for containers then we shouldn't be too restrictive and also accept non-Docker links. Maybe it would be enough to label Docker-specific links with a whale and non-Docker links with a container?
• Docker isn't container-only, but also provides other abstractions... thinking of Swarm (orchestration), LinuxKit (virtual machines), InfraKit (high-level orchestration?). Given a category orchestration we should either include Kubernetes or clearly state that we focus on Docker. Including Kubernetes would show our openness, but might also overwhelm ourselves with the sheer amount of tools and pace the community is evolving.

I guess the important (maybe the hardest) part is finding the right categories. How we're going to structure them depends on how much they overlap. I would still propose to keep the name awesome-docker, regardless of the actual contents or links to other awesome-<list>s.

from awesome-docker.

@veggiemonk, will leave my feedback at weekend

from awesome-docker.

Made a little something to try things out (see #584)

from awesome-docker.

@veggiemonk your PoC #584 is a very nice start to go further. The ability to filter the list by some keyword(s) is handy to find the needle in the haystack (if any). To generate the metadata one can utilize Travis CIs cronjob feature for one ore two builds each day or even each hour 😜 The number of open and closed issues and push requests might by interesting as a indicator of 'activity'. The number of forks might be interesting too. The card (a project) might be look like an entry of the periodic system with its key numbers ...

I agree on keeping the introduction aka »Where to start«.

IMHO if #584 is stable (some minor issues exists) it should be contained within the website. We can improve it step by step as we done some months ago by re-organizing the list.

from awesome-docker.

Still fixing the #584 with the sorting...

I think having those data being fetch automatically once a day is good enough.

We still need to think of something to integrate the "where to start" section.

from awesome-docker.

What do you think about this?

• keeping the list as "awesome-docker" since it's popular and referenced to many places
• we extend to content to more than just docker by adding new labels and categories (emojis?)
• we clearly state when the content is docker specific and when it is not.

The awesome list called awesome-linux-containers doesn't have a lot of attention. And in the name there is "Linux" which would exclude many project running on windows.

If we want to create a new list, let's make it a organisation on its own.

There is a lot of options, let us know what you think. There is no right or wrong answer.

from awesome-docker.

Ok, I had a few ideas and this got out of hand quickly....

• The fact that we have only one page makes it's easy to press CTRL/CMD + F to search for keywords. So splitting into many lists might be more a hassle just for the sake of having clearly defined category but that's just my personal opinion. I would like to have one list with filtering and sorting.

• The way to display the content is important. One thing I really like about the CNCF landscape is the ability to apply many filter and sort order. This requires some data to be stored, this is why I started working on this a while ago: https://github.com/veggiemonk/awesome-docker/tree/master/data

• The list is a README.md of a github repository, converting it into a website is kind of a big change. But that change can prevent us from being overwhelmed by the amount of projects that we need to evaluate if we have tools and the data.

• I want to keep the commitment low. Like a side project, not a full time job. So we are talking automation. We can already gather some data from github. For the documentation, the installation instructions and a "try it yourself" example, we can create a form to store it. So when a PR is created, some fields of the PR are parsed. If the field are not filled, they will appear blank in the table. So we can quickly see what are the projects that are higher quality than others. Let me know what kind of data would you like to see in the table. Like how many starts since last month/week ? Number of open issue? number of PR? and so forth...

• When the scope of a project is too big, it is time to scope it down and iterate over. Everybody seems to agree that we should include all OCI related projects. Instead of curating a list, we gather every projects and their metadata in order to categorize/list them in the best way possible. Then we curate predefined filters such as "docker-only", "windows-only", "osx-only", "for-developers", "for-sysadmin", "for-learning", "beginner-friendly" and so on...

• Let's keep the Where to start section and stay beginner-friendly. Many projects are too complex to understand just by reading a description. Containers are completely new concept for a lot of people and we should aim at making their learning curve less steep.

Let me know your thoughts...

from awesome-docker.

Gradually getting there.... it needs a few more features though before we can migrate

from awesome-docker.