On 5 May 2015 at 07:38, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le samedi 18 avril 2015 10:55:00 Shane Curcuru a écrit : >> LOL, below. >> >> I highly recommend separating the model from the views, so that we can >> efficiently enable our volunteer's energy here to actually accomplish >> something valuable. > +1 > >> >> So let's work on stuff to do that excites us, but remember to keep the >> technical problems focused on what this PMC believes we can truly create >> and maintain going forward. >> >> Don't worry about everything at once. Just focus on separate bits: >> >> - Method to scrape source data from our various definitive or even not >> completely definitive but very close places (txt files, websites, LDAP) >> >> - Model and data source that actually holds info about committer lists >> and project metadata. I'm betting Daniels' projects-new does this very >> well already. > +1 it's a perfect starting point: just need to document and continue to > improve > then I started by documenting what are the current information sources used > for generating projects-new.a.o json files: > see https://projects-new.apache.org/json/foundation/ and > http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/README.txt?view=markup > >> >> ---------- >> - Stable API to get at that model. Would be really nice if we did this >> just once, so that people working above here don't interfere with people >> working below here. >> ---------- > +1 > > Since there are multiple information sources for TLPs/PMCs/committers, I think > I will consolidate to avoid what's currently happenning: the projects.js (ie > one visualization) contains a lot of code to consolidate the multiple > information sources > If the consolidation is done server side, in the generation scripts, it will > be easier to use for projects.js and any other tool wanting to do other future > visualizations > >> >> - Visualizations. There's lots of different stuff to do here, and I >> think it'd be super helpful if everyone just did something they want, >> and then show us the code. > +1 > >> >> Sure, there's lots of "what is important" to focus on, but I for one >> would love to see real examples of all the cool visualization libraries >> out there, and I know a couple folks already use some of them. >> >> - UI additions for the projects-new/projects websites, which are >> featured at the top level of a.o. I.e., this is our "projects >> directory", how can we better lead people who arrive there at what they >> want to know? > at the moment, I'm not trying to add any new UI, but improve the consistency > of displayed data, since current state is not really consistent: some PMCs are > not displayed, probably because they have not provided any DOAP file. But even > without DOAP file, we have a lot of data to display for a TLP, most of what we > display for a TLP (ie a project that does not have any subproject) > > I think we really have some data model problem here regarding what is a > "project's DOAP file": sometimes, a project is a PMC, sometimes a project is a > deliverable, more like what is called in projectsnew.a.o a "sub-project"
That is not how I understand DOAPs. DOAP == Description Of A Project i.e. some releaseable artifact. A single PMC may have multiple projects, each with its own releases and repositories. These are modelled quite well in the DOAPs that PMCs have created. Information about the PMC which manages the projects is NOT stored in a DOAP, it is stored in a PMC data file. This is referenced from a DOAP using <asfext:pmd rdf:resource="URL"/> where URL is either an actual URL of a PMC data file or a dummy URL e.g. <asfext:pmc rdf:resource="http://<pmcname>.apache.org" /> which leads to a file here: https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files/<pmcname>.rdf > if you look at https://projects-new.apache.org/projects.html?pmc, typical > cases for that are: > - Incubator: there is the "the Incubator project", displayed without DOAP file > since the incubator has special source info, and many sub-projects which > provide DOAP files > - Commons: there is no "Commons' DOAP file", then no TLP... on sub-project is > quasi randomly chosen... Common's DOAP file, if it existed would not release > anything, it"s a pure "organizational" project There is an ambiguity here: project can mean an organisational entity and project can mean a releaseable artifact. There are different RDF files for the two meanings; only the artifact has an associated DOAP. > - Ant: there is an Ant DOAP file that represent the TLP and the main released > artifact No, it only links to the TLP = PMC data file, it does not represent the TLP. The Ant DOAP file only represents the Ant product. > I chose Commons, but it could have been HttpComponents or Logging Services, or > Lucene (Lucene have been very clear that there is a "Lucene core" sub- > project), Web Services, Axis, Xalan, Xerces, XML Graphics, Attic, Creadur, DB, > jUDDI, Tcl > > I chose Ant, but it could have been Velocity, MINA, Directory, HTTP Server, > MyFaces, Tomcat > > >> >> - (future) UI additions for *other* places. It would be awesome, for >> example, to provide a tiny scriptlet that any project could inject in >> their website that displays a "see also" menu. That would link to a >> specific URL on projects.a.o that would say "hey, you came from >> Cassandra, here are: -other big data projects, -other projects in Java, >> -other projects with the same committers... etc." as a service. >> >> - Shane > > I'll continue tonight on this > Any help appreciated > > Regards, > > Hervé >
