Minutes of the Foundation IRC meeting - September 12, 2012

wiki: https://live.gnome.org/FoundationBoard/Minutes/IRC20120912

= Minutes for Foundation IRC Meeting of September 12th, 2012 =

== Attendance ==
 * For the board:
   * Emmanuele
   * Joanie
   * Tobi
   * Shaun
   * Andreas

== Agenda ==
 * Role and scope of the Release Team
   * Continuation of the discussion from the AGM at GUADEC 2012.
   * http://www.0d.be/2012/08/03/guadec-2012/
   * http://people.gnome.org/~ebassi/01-release-team.pdf - slides deck
from the AGM
   * Clarification of the release rules and scope
     * http://live.gnome.org/ReleasePlanning/WhatWeRelease
   * The discussion at the AGM had to be interrupted for time constraints
   * The community considers the release-team as being in a good
position to ensure the cooperation between maintainers in order to
release GNOME
     * Some members of the community also would like to have an
"arbiter" to resolve eventual conflicts
     * The arbiter could be the board, the release team, or a new team
   * Examples of issues faced by the release team
     * Deferring the python3 dependency
     * Acting as support for modules, by promoting them to the
official moduleset, and posting semi-regular updates on their status
   * Communication issues between maintainer
     * Example: Nautilus UI changes in 3.5
     * Is it part of the release team remit to pester maintainers to
communicate sweeping changes to a module in the release moduleset?
     * Another option: revert to a previous version until the
regressions are fixed?
       * This already happens at the feature level (unmet features are
pushed to the following cycle) and at the moduleset level (modules are
pushed back or removed)
       * Examples: nautilus-cd-burner, gstreamer-1.0
   * Is the release team also in charge of the project's direction?
     * It would mean having the input or the presence of the design
team inside the release team decision making process
   * Traditionally, the release team's role was to capture consensus
in the community
     * The community sets the direction, and the r-t resolves
conflicts between modules
     * But what if the community thinks that the r-t sets the direction?
   * Proposal: use GUADEC to set the direction of the project
     * Every other GUADEC sets the roadmap for the following two years
     * Reflected also in the accepted talks
     * Issue: possible marginalization of the maintainers and
community members that cannot attend
     * Prior art: MozCamp
     * The issue of the direction of the community should be resolved
within the community, through high bandwidth communication channels
(e.g. GUADEC); after a period of public RFC, the release team is in
charge of ensuring that the direction is followed through.
       * The release team would be the "editor" of the project
direction, in terms on maintaining the modulesets that define GNOME
     * We need a benchmark to verify that the process is followed and
it's working
       * Example of a benchmark for the Testable initiative: in the
next round of outreach programs, all students should be able to build
GNOME without going through jhbuild pains
  * Venues of communication
    * Go back using desktop-devel-list as a development mailing list,
and require maintainers to join
    * desktop-devel-list has been used for multiple communication issues
    * It is difficult to know who the maintainers are
    * We could use the DOAP files and publish the current maintainers
    * '''ACTION''': fredp to publish the list of maintainers extracted
from the DOAP files on git.gnome.org
    * Proposal: use another mailing list for maintainers?
    * Issue: should it be public?
      * It should be up to the maintainers to decide
    * Issue: having yet another mailing list may not be well received
  * Enforcing the project's direction
    * The release team is already partly doing that by maintaining the moduleset
    * How to handle forks?
      * External forks are not under GNOME's purview
      * Internal forks should not happen
      * Maintainance releases from the old 2.x modulesets are not
controversial and should not be considered forks
    * Case study: Nautilus in the 3.6 cycle
      * Definite lack of communication from the maintainers
      * Feature proposal period was not used
        * The rules were not clear for features involving a single project
      * Changes involved a set of feature removals
      * Proposal: the feature proposal period should also be used in
case of changes involving a single project
        * Constraints: does it involve removing features? is the
module part of core? is the module user visible?
        * The release team should exercise the option to punt the
module out of the release moduleset until regressions are addressed or
a sizeable discussion (determined by the release team) happened on the
desktop-devel list
        * Some of the criteria could match the ones we use for the UI
freeze requests, but the bar should be set higher

 * Inclusion of the Commit Digest on Planet GNOME
   * Requires amending the PGO policy
   * Not really controversial
   * Using a separate style to visually differentiate the feed on the Planet
   * '''ACTION''': Emmanuele to contact the PGO editor to add the
commit digest to the Planet, using a slightly modified style

== New Action Items ==
 * '''ACTION''': fredp to publish the list of maintainers extracted
from the DOAP files on git.gnome.org
 * '''ACTION''': Emmanuele to contact the PGO editor to add the commit
digest to the Planet, using a slightly modified style

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/