Refactoring: list of sections

[veggiemonk]

So far we have:

• [ ] Continuous Integration / Continuous Delivery
  • [ ] CI Services
• [ ] Deployment and Infrastructure
• [ ] Developer Tools: API to access docker via code
• [ ] Development Environments: tools to help developing with docker
• [ ] Dockerfile: example to help build lean and clean docker images
• [ ] Garbage Collection: to keep your dev env clean
• [ ] Hosting Images (registries)
• [ ] Image Builder: to build those lean and clean docker images
• [ ] Linter / Validator: gives tips on how to build lean and clean docker images
• [ ] Local Container Manager
• [ ] Monitoring & Logging
  • [ ] Monitoring & Logging Services
• [ ] Networking
• [ ] PaaS
• [ ] Remote Container Manager / Orchestration
• [ ] Reverse Proxy
• [ ] Security
• [ ] Serverless
• [ ] Service Discovery
• [ ] CaaS - Services for running containers
• [ ] Terminal User Interface
• [x] Testing
• [ ] Utilities <--- this one is a really bad name!
• [ ] Volume management and plugins
• [ ] Web Interface

---

Local container manager, web interface and terminal user interface should be sub-section under the section called "Docker interface" or "Docker UI". This section is typically for people who don't like command line tools and/or just want to try docker to see what it is.

Everything related to building, linting images should be under one section called "Docker images". This section would be for those who are already using docker and want to build better images for example.

Everything related to developing with docker (dev env, dev tools, utilities(?) ) should be under one section called "Developing with Docker" (see how long I looked for a good name :p). This section is for those who want to build a project by using docker for example.

And the rest should be under one section called "Managing Docker containers" or something similar. This section would be for DevOps who already manage docker containers in production.

Those are the 4 main sections so far, would love to hear other opinions on that.

[veggiemonk]

@Moshe-Immerman Nice job !!!

[moshloop]

Maybe we should break it down by use case e.g.

Running

• Composition
• CLI
• Orchestration
• Hooks
• Web
• Wrappers (e.g. dexec, udocker, dray, fugu etc)

Docker Images

• Building
  • System tools
• Linting
  • Registries

Development Environments

Development on Docker

• API Clients

• Service Discovery

• Serverless

Deployment

• Setup / Installation
• CaaS
• PaaS
• Monitoring
• Networking

[ghost]

Good initiative @Moshe-Immerman @veggiemonk .

Another point would be that we should describe what each (sub)category is all about. So, it's easy for contributors adding new tools. A good starting point would be like awesome-java and/or as @veggiemonk already did started like above.

[agebhar1]

another approach - or in addition - could be tagging by tags, if a project doesn't fit exactly into one category

[veggiemonk]

@agebhar1 Good idea but I have a little bit of trouble when it comes to actual use cases. Do you have an example? What would be the tags in our case ?

[moshloop]

I like the concept of tagging, but perhaps using icons instead of text otherwise we run the risk of going over 1 line.

e.g. awesome-java uses:

Commercial:

and I can think of a few more:

• ancient (but still awesome/relevant)
• CLI / terminal
• library
• beta / upcoming
• docs / tutorial

[veggiemonk]

I like this icon/tagging idea.

For the sections, if we are going to sort them by use case, the name of the subsection should also be a use case, not just a category/type ! So I don't really like this separation because it is based on the projects, not really on the people who are looking for those projects.

We should give a little thought on WHO it would help rather then WHAT it is... Because projects can pivot/evolve/...

But here is some ideas:

Running & Deployment --> Managing Containers --> Container Operations

• Composition --> Container Composition
• Terminal User Interface: to help manage docker container from a terminal
• Web <-- Docker web UI : to help manage docker container from a browser
• Workstation Installation <-- For non production usage e.g. macosx
• Deployment and Infrastructure
• Orchestration <-- might cause an overlap with PaaS, how to differentiate the 2?
• CaaS (do we have any project that is not a paying service there? )
• PaaS <-- Move to Orchestration or CaaS for EC2 options?
• Monitoring
• Networking
• Reverse Proxy
• Security
• Service Discovery
• Volumes management / Data

Docker Images

• Building
• System tools for lack of a better name: project to help containerize an app --> Inside Container Tools ? please help with the naming because System tools means nothing to me.
• Dockerfile: example to help build lean and clean docker images
• Linting
• Registries

Development on with Docker

• API Clients
• CI/CD
• Development Environments
• Garbage Collection: to keep your dev env clean
• Docker Event Hooks
• Serverless
• Testing
• Wrappers (e.g. dexec, udocker, dray, fugu etc)

Services based on Docker ($$$)

• CI/CD
• Monitoring
• CaaS
• Registries
• Security (?)
• PaaS

ICONS/TAGS Commercial Managed Hosting Option Premium/Free trial Open Source Library CLI/Terminal Web UI Beta / Upcoming Great Documentation (don't really care about tutorials) Heart (if some of us have a project crush ;-)

This is not perfect but if we organize this list according to what people are looking for, it is going to make our lives easier. By the way, how is the Moby project organized ? Because they might have given some thought about that and we might want to learn from what they struggled with.

Feel free to reorder/change/comment/whatever so that we get the best ideas...

[vegasbrianc]

What about naming the section Managing Containers -> Container Operations?

[veggiemonk]

See @Moshe-Immerman PR for the changes (good job!) #397

[ghost]

In my opinion, we should continue discussing here instead of opening new PR as it's going to be messy. The comments here are editable anyway.

Besides, I was about to refresh the Useful Resources section here. E.g. awesome-java resources looks very nice. We could do a similar approach. Putting Videos, Twitter, Communities also under this section.

• Useful Resources
  • Awesome Lists Awesome lists related to Docker
  • Best practices How to be efficient within the Docker ecosystem
  • Blogs Interesting blogs to read
  • Communities Meetups, Conferences?
  • ~~Twitter Active accounts to follow. Descriptions from Twitter~~
  • Raspberry Pi / ARM Yeah! You can run Docker on single-board computers, too
  • Security How to secure containers
  • Videos Interesting videos

Just a quick idea and it's still far from perfect.

[moshloop]

@devhkr The comments may be editable, but the comments themselves are not comment-able so it is really difficult to discuss each line

[ghost]

@Moshe-Immerman I agree with you and I see your point.

However, a PR could also lead to long discussions. I know, this is where everyone can comment on code-lines. Furthermore, what if someone has a very different idea/suggestion? Long discussions start again. In my opinion, we should start small keeping the following comments by @veggiemonk in mind:

We should give a little thought on WHO it would help rather then WHAT it is...

In case of doubt, just imagine yourself as someone who doesn't know much about docker and is looking for a nice, simple [insert name of the section here]... That's what awesome lists are for...

We all value each other's contribution and time, but making smaller things speed up review time and it’s easier for the reviewers to understand the context and reason with the logic.

[veggiemonk]

@devhkr nicely put

[moshloop]

@devhkr in terms of resources I am of the belief they should be inlined e.g. Under the Docker images section we have both awesome docs/videos with tags and awesome software) however in the spirit of keepings things small I think the resources section should be left for separate issue/pr

[veggiemonk]

OK I will give this refactoring a try this week (or weekend) to see what we can do with it.

[ghost]

Sorry folks, was AFK the whole weekend while having our discussions in mind.

Just a quick feeback from my side, again:

@Moshe-Immerman What do you mean by

in terms of resources I am of the belief they should be inlined e.g. Under the Docker images section we have both awesome docs/videos with tags and awesome software)

Useful Resources will be split up then? In my opinion, we should have two main sections (like awesome-java):

• Tools
• Useful Resources

@Moshe-Immerman @veggiemonk Instead of "Ancient, Archive...", how about Legacy tools ? So, we can list like Docker Toolbox etc.

Have a good start in the new week. TTYL

[veggiemonk]

@devhkr @Moshe-Immerman Agree with Legacy instead of ancient

[ghost]

Some additional remarks from me:

• I like the tagging/icon idea only if we have website with filter functions like devopsbookmarks.com. The main idea behind tagging is that people can look up for tools, or articles, by specific selections. In addition, we have like 11 icons in which our list looks too fancy then. Also, for contributors it's tedious adding all the tags/icons on their PRs. We have set enough rules for them. If we stick on the tagging/icon stuff, then we should downsize the number of icons to the minimum/essentials:

  • Commercial
  • Beta
  • Terminal (a)
  • Web Based (b) a,b) I quickly went through the list, almost all tools are either CLI or web based or both.

• Still unsure if we shall mix everything with useful resources section. In my view, people are mainly looking for tools, less documentations. So, personally, we should better have separation of Tools and Useful Resources like awesome-java. We may hint to the resources section at the beginning of the README file.

[moshloop]

How about we leave the resources section (along with it's icons) for another time/issue?

What about just these icons:

Commercial Beta Windows OSX

i.e. By default, we assume all tools support linux and possibly Windows and/or OSX, if they don't support Linux only then do we indicate which platform it targets instead

[veggiemonk]

this is done #408 #404 #406