----- Original Message -----
> This looks really good to me.
>
> I only have two questions:
> 1.) What's involved in converting form a user to an org account? Do you
> need any help from us?

It's trivial*. There's a "Convert to Organization" (or similar) button.

*It's possible that there's some not-obvious-to-non-sysadmins thing that makes it more complex from tykeal's perspective.

One consideration with regard to converting to an org is that we'd be able to make use of DockerHub's "Collaborators" feature. Collaborators have image push access to the org, and perhaps more importantly (since we're using automatic builds) would be able to edit the "Short Description" of repos as well as adding additional tags.

NB: Long descriptions are automatically created from the READMEs in directories containing Dockerfiles pointed at by Automatic Builds. Short descriptions show up in different places. Both should exist for every DockerHub repo.
NB: The same Docker artifact can be pointed at by multiple tags. For example, ubuntu:14.04, ubuntu:trusty and ubuntu:latest are exactly the same thing[1]. This feature is nice for clearly expressing some situations, as the Ubuntu example shows.

One option is that we could ignore this feature and submit help desk tickets to update short descriptions and add tags. This might be the simplest solution, but it would create more work for our wonderful admins.

Another option, and one that I believe is fairly common, is to make the folks who have push access to the Dockerfiles the same people who have push access to the DockerHub repos they are hosted in. As those DockerHub users make changes to Dockerfiles, they would be responsible for writing/updating short descriptions and adding additional tags. From a permissions perspective, modifying a Dockerfile that's pointed at by an Automatic Build is basically equivalent to having DockerHub push access. Since the Dockerfiles live in the Integration team's repo, committers to that project would already be roughly equivalent to DockerHub collaborators. A simple-ish solution is giving push access to Integration committers that need it.**

**Disclaimer: I'm currently being voted on as a potential new Integration committer.

If we think the collaborators feature is going to cause a long, painful discussion about how to do it properly, I'm totally okay with ignoring it. Overall, I think making Integration committers == DockerHub collaborators makes sense and would lower the overhead required for keeping the DockerHub org well-organized. NBD to me either way.

[1]: https://registry.hub.docker.com/_/ubuntu/

> 2.) Do you have ideas about how we should let people pick ${repo} names?

I would leave it at advising them to keep it short and descriptive. The Integration committers who merge the Dockerfile (and potentially create/edit the Automatic Build if we use collaborators) should vet the name.

> Should we have the ODL project name included?

I'm not sure if "ODL project name" means "ODL" or something like "OVSDB". If it means "ODL", than no, that'd be redundant. The ${org} part of the namespace would already be "opendaylight". If it means something like "OVSDB", then I think that would likely be a good choice for many images. There may be some, however, that a project name doesn't make sense for (example: WCBench, the performance test tool I wrote).

Great questions!

Daniel Farrell
Software Engineer, Red Hat SDN Team
https://twitter.com/dfarrell07

> --Colin
>