[modules-dev] Open Bugs/RFEs in java/module

[Stephen J. McConnell]

On Fri, 2008-01-18 at 14:12 -0800, Andreas Sterbenz wrote:
> Stephen J. McConnell wrote:
> > 
> > Can you provide a summary of what this periodic report actually is (as
> > opposed to the other periodic report that appears with the same subject
> > that lists some 39 outstanding bugs)?
> 
> The empty report was just due to some changes in an internal system that 
> this report generation script did not handle gracefully. I have fixed that 
> and things should be back to normal going forward.

Latest reports seem to demonstrate that the problem has been solved (we
are back to the 39).  In the meantime - can you provide some details
about the codebase in question here?  Are the periodic reports
reflecting actual work-in-progress or are we simply looking at an
automated process that is linked to the last public release of the
codebase?

Something that would be much more interesting would be a periodic progress report with details of:

  a) EG activity summary (294 and 277)
     - new or updated info
     - summary of external comments and info
       (e.g. out in blogland, or the latest youtube
       presentation)
  b) legal and administrative processes
     - political issues/obstacles
     - licensing issues/obstacles (e.g. publication 
       of strawman documentation, revision to spec 
       licensing, ...)
  c) codebase development
     - technical issues/obstacles
     - infrastructure progress (i.e. there are lots
       of outstanding promises re. integration into 
       the OpenJDK process - mercurial migration, 
       synchronisation with version 7 ...
  d) roadmap
     - admin stuff (e.g. changes on the EG)
     - outlook for the next quarter (priorities, 
       targets, expectations)

All of the above would be consistent with section 2.1.1 of JCP 2.6 ([1]): 

  "While Spec Leads are free to operate Expert Groups in 
  whatever style they feel is most appropriate, they are 
  encouraged to choose a style that provides maximal 
  transparency to the Expert Group, community, the EC 
  members and the public. The PMO provides Spec Leads with 
  tools and techniques for making the actions of their 
  Expert Groups transparent, and the EC members expect Spec 
  Leads to carefully choose which tools are best for their 
  Expert Groups and commit to using them. Transparency is 
  valuable to everyone in the community, especially the 
  Expert Group, because it offers broader feedback to the 
  group and helps build broader support for the final spec." 

What do you think?

Cheers, Steve.


> 
> Thanks for pinging,
> Andreas.
> 

-- 
Stephen J. McConnell
mailto:mcconnell at dpml.net
http://www.dpml.net