I've been interacting recently with several new contributors (to Trove) and I can certainly attest to the fact that people appear to browse the source repository and read the README's.
Flavio makes a good point that it would be good to provide a short summary of the project's capabilities in some common place for all projects, and it may then be easy to automate the generation of a single webpage for all of the projects that one could treat as a landing page. To Doug's point about tags; I would recommend that the tags be used to also indicate which section of the main landing page the project should land. For example, does the project fall under "compute", "storage", or "networking" or some such suitable taxonomy of projects that will help to render a meaningful top level (landing page) for all projects in some intuitive organization for potential contributors and users. -amrith > -----Original Message----- > From: Hayes, Graham [mailto:graham.ha...@hpe.com] > Sent: Wednesday, October 12, 2016 11:14 AM > To: OpenStack Development Mailing List (not for usage questions) > <firstname.lastname@example.org> > Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in > README files > > On 12/10/2016 16:08, Doug Hellmann wrote: > > Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200: > >> Greetings, > >> > >> One of the common complains about the existing project organization in > the big > >> tent is that it's difficult to wrap our heads around the many projects > there > >> are, their current state (in/out the big tent), their tags, etc. > >> > >> This information is available on the governance website. Each > official > >> project team has a page there containing the information related to the > >> deliverables managed by that team. Unfortunately, I don't think this > page is > >> checked often enough and I believe it's not known by everyone. > >> > >> In the hope that we can make this information clearer to people > browsing the > >> many repos (most likely on github), I'd like to propose that we include > the > >> information of each deliverable in the readme file. This information > would be > >> rendered along with the rest of the readme (at least on Github, which > might not > >> be our main repo but it's the place most humans go to to check our > projects). > >> > >> Rather than duplicating this information, I'd like to find a way to > just > >> "include it" in the Readme file. As far as showing the "official" badge > goes, I > >> believe it'd be quite simple. We can do it the same way CI tags are > exposed when > >> using travis (just include an image). As for the rest of the tags, it > might > >> require some extra hacking. > >> > >> So, before I start digging more into this, I wanted to get other > opinions/ideas > >> on this topic and how we can make this information more evident to the > rest of > >> the community (and people not as familiar with our processes as some of > us are). > >> > >> Thanks in advance, > >> Flavio > >> > >>  http://governance.openstack.org/reference/projects/index.html > >> > > > > Is your proposal that a tag like release:cycle-with-milestones would > > result in a badge being added when the README.rst is rendered on > > github.com? Would that work for git.openstack.org, too? > > > > I agree that the governance site is not the best place to put the > > info to make it discoverable. Do users look first at the source > > repository, or at some other documentation? > > > > Doug > > I like this idea. > > I know when I am looking at software, I look at the source repo > initially. > > We could do it in the readme, and maybe re-use it in the docs as well? > > I would be willing to dig in and help if needed. > > - Graham > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev