Not sure where to comment, so I'll top post. Some of the data that you mentioned doesn't need to be in the status file as it can be generated from other sources. For example: https://whimsy.apache.org/board/agenda/json/podlingnamesearch. I'll refactor that code and add that information to the ppmc pages of the roster tool.
YAML is more human editable than JSON. As Sebb points out elsewhere, it also supports comments. One thing that whimsy should do is spit out a digested and accumulated set of information in JSON which can be read by other tools. A good place for a public view would be the phonebook application. I see as I typed this Bertrand brought up clutch and graduation checklist. I see those as items that can be incorporated into the roster tool, with the added value that this tool is both read/write. See something that needs to be changed? Given the right permissions, you can fix it right there, and interested parties will be notified of the change. I've already added a button to the bottom of the PPMC roster pages to help you draft a graduation resolution. At the moment, it doesn't do anything more than display the resolution which you can copy/paste. This not only will save a few minutes, the resolution will contain the correct names and ids. - Sam Ruby On Tue, Jun 6, 2017 at 7:11 AM, John D. Ament <johndam...@apache.org> wrote: > On Tue, Jun 6, 2017 at 6:40 AM sebb <seb...@gmail.com> wrote: > >> On 6 June 2017 at 04:22, John D. Ament <johndam...@apache.org> wrote: >> > As a follow up to my prior question, ( >> > >> https://lists.apache.org/thread.html/31119aafbc4260720d222666f3efd01f2fe2975e424039ea539c9cb6@%3Cgeneral.incubator.apache.org%3E >> > ). >> > Looking at our current tracking file for podlings, I wonder how much of >> the >> > information is useful. Let's use Traffic Control as a for instance here: >> > http://incubator.apache.org/projects/trafficcontrol.html (its nothing >> > they're doing bad, I just happened to grab them) >> >> However their status file does not contain the full range of data that >> is normally present. >> e.g. no website link, no repo link, no champion/mentors >> > > > Good points. I think we definitely want to have areas for source repos, > the website (override-able?), confluence keys, etc. > > As mentioned, I'm less concerned about roster information at this point on > the status page because of Whimsy. > > >> > - The committer list is fully replaced by the Whimsy Roster Tool >> > - Do we care about News? Shouldn't this be captured in the quarterly >> > reports? >> >> It's easier for outsiders to read here. >> It perhaps encourages the podling to think about progress. >> >> > So maybe a free form area for news items? > > >> > - I see a lot of usefulness in tracking the Podling Name Search request >> > - The first few questions have to do with the actual vote. I think these >> > can best be captured by two fields - "Sponsor" and "Date Accepted into >> > Incubator" >> > - Infra section - I think all of these are important, we may want to >> expand >> > some of the options to include gitbox and other tools that are managed >> > outside our hosted infrastructure. >> > - Mentor section - I'm not sure how useful this is, but I want to get >> > others opinions. Mentors being on the IPMC is a pre-req for votes, so >> this >> > is hopefully less of an issue. >> > - Copyright - I believe this can be replaced by a single field "Date SGA >> > Received". Copyright headers are subjective. >> > - Add a new field "Date of IP Clearance" for projects using IP Clearance >> > instead of SGA (e.g. already Apache v2) >> > - Verify Distribution Rights - I think this can be rewritten to instead >> say >> > "Date of Release with no Source Licensing Issues" (listing out the bullet >> > points mentioned here) and a new field "Date of Release with no Binary >> > Licensing Issues" (indicating some of the Cat-B/Optional Cat-X stuff) >> > - I don't think we need the committers section at the bottom, since the >> > roster would be controlled from Whimsy itself. >> > >> > Is there more information that we could leverage to make this easier to >> > watch? I figure that once a podling has filled out all of these (except >> > for one of SGA/IP Clearance) we can tell them they're close to >> graduation. >> >> I find the status files useful for quickly finding information about a >> project that would otherwise require a trawl of lots of pages of the >> website. >> It also allows the PPMC to record info about the project (e.g. git >> repo, JIRA etc) before the website has been set up. >> > > > I've been going back and forth on this. I think you're thinking along my > lines - should the status file be public or private. I think we need a > public read only version of the status, in addition to the writeable > version. > > >> >> It is useful beyond just tracking progress to graduation/retirement. >> >> Having a single page to show summary info and track the status is >> something I think we should keep. >> But I agree it needs to be easier to maintain and it should be obvious >> when bits of information are missing. >> >> > Huge +1. My biggest issue is that it's arbitrary HTML. Any podling can > add stuff as they see fit, or remove sections, and it's not obvious. > > >> This would be easier to do if the page were generated from properly >> structured data files. >> >> Could the data all be handled in podlings.xml? >> Or should podlings.xml be split into individual files? >> > > I feel like splitting is more desirable. From what I'm seeing, it's adding > 20 new data elements. Merging podlings.xml + the status file into a new > file makes a bit more sense. JSON is easier to parse, but leaves more to > be desired from someone manually tweaking the file. > > >> >> > John >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
