mirror of
https://github.com/veggiemonk/awesome-docker.git
synced 2026-03-09 15:32:11 -05:00
Refactoring: list of sections #23
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/awesome-docker#23
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @veggiemonk on GitHub (Jul 25, 2017).
Originally assigned to: @gesellix, @vegasbrianc, @moshloop, @agebhar1, @veggiemonk, @dmitrytokarev on GitHub.
So far we have:
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 commented on GitHub (Jul 25, 2017):
@Moshe-Immerman Nice job !!!
@moshloop commented on GitHub (Jul 25, 2017):
Maybe we should break it down by use case e.g.
Running
Docker Images
Development Environments
Development on Docker
API Clients
Service Discovery
Serverless
Deployment
@ghost commented on GitHub (Jul 25, 2017):
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 commented on GitHub (Jul 25, 2017):
another approach - or in addition - could be tagging by tags, if a project doesn't fit exactly into one category
@veggiemonk commented on GitHub (Jul 26, 2017):
@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 commented on GitHub (Jul 26, 2017):
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:
@veggiemonk commented on GitHub (Jul 26, 2017):
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 OperationsWeb<-- Docker web UI : to help manage docker container from a browserPaaS<-- Move to Orchestration or CaaS for EC2 options?Docker Images
System toolsfor 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.Development
onwith DockerServices based on Docker ($$$)
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 commented on GitHub (Jul 26, 2017):
What about naming the section Managing Containers -> Container Operations?
@veggiemonk commented on GitHub (Jul 28, 2017):
See @Moshe-Immerman PR for the changes (good job!) #397
@ghost commented on GitHub (Jul 28, 2017):
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 Resourcessection here. E.g. awesome-java resources looks very nice. We could do a similar approach. Putting Videos, Twitter, Communities also under this section.Awesome lists related to Docker
How to be efficient within the Docker ecosystem
Interesting blogs to read
Meetups, Conferences?
TwitterActive accounts to follow. Descriptions from Twitter
Yeah! You can run Docker on single-board computers, too
How to secure containers
Interesting videos
Just a quick idea and it's still far from perfect.
@moshloop commented on GitHub (Jul 28, 2017):
@devhkr The comments may be editable, but the comments themselves are not comment-able so it is really difficult to discuss each line
@ghost commented on GitHub (Jul 28, 2017):
@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 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 commented on GitHub (Jul 28, 2017):
@devhkr nicely put
@moshloop commented on GitHub (Jul 28, 2017):
@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 commented on GitHub (Jul 30, 2017):
OK I will give this refactoring a try this week (or weekend) to see what we can do with it.
@ghost commented on GitHub (Jul 30, 2017):
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
Useful Resourceswill be split up then? In my opinion, we should have two main sections (likeawesome-java):@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 commented on GitHub (Jul 31, 2017):
@devhkr @Moshe-Immerman Agree with
Legacyinstead ofancient@ghost commented on GitHub (Aug 4, 2017):
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:
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
ToolsandUseful Resourceslike awesome-java. We may hint to the resources section at the beginning of the README file.@moshloop commented on GitHub (Aug 4, 2017):
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 commented on GitHub (Aug 28, 2017):
this is done #408 #404 #406