incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Contents of Podling Status Tracking
Date Tue, 06 Jun 2017 11:49:11 GMT
On Tue, Jun 6, 2017 at 7:44 AM Sam Ruby <rubys@intertwingly.net> wrote:

> 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.
>

I don't see the code that generates this.  Where did it come from?


>
> 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.
>

Agreed.  All of the changes I have locally are going into
public_podlings.json first.  Once that works, we can start to incorporate
into other pages.


>
> 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.
>

I gave it a field run, it looks nice.


>
> - Sam Ruby
>
> On Tue, Jun 6, 2017 at 7:11 AM, John D. Ament <johndament@apache.org>
> wrote:
> > On Tue, Jun 6, 2017 at 6:40 AM sebb <sebbaz@gmail.com> wrote:
> >
> >> On 6 June 2017 at 04:22, John D. Ament <johndament@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-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message