Version 1 by Matthew Weier O'Phinney
on Jun 22, 2012 16:14.

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (69)

View Page History

{toc}
<ac:macro ac:name="toc" />

h2. Information
<h2>Information</h2>

* Date: 20 June 2012, 20:00-21:00 UTC
* [Agenda|2012-06-20 Meeting Agenda]
* Moderator: Matthew Weier O'Phinney (nickname weierophinney)
* Next meeting: 27 June 2012
<ul>
<li>Date: 20 June 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-06-20 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 27 June 2012</li>
</ul>

h2. Summary

h3. Adopting PSR-1 / PSR-2 coding standards
<h2>Summary</h2>

(Search for "20:02:25" in the log.)
<h3>Adopting PSR-1 / PSR-2 coding standards</h3>

PSR-1 and PSR-2 have recently been accepted, and they provide the kernel for a coding standards recommendation:
<p>(Search for &quot;20:02:25&quot; in the log.)</p>

* [PSR-1|https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-1-basic.md]
* [PSR-2|https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-2-advanced.md]
<p>PSR-1 and PSR-2 have recently been accepted, and they provide the kernel for a coding standards recommendation:</p>

Currently, the only change this would require in the current ZF2 coding standards is to have a "use" statement _per_ import (vs. a single "use" statement, with each import separated by commas).
<ul>
<li><a href="https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-1-basic.md">PSR-1</a></li>
<li><a href="https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-2-advanced.md">PSR-2</a></li>
</ul>

There was no debate about whether or not we should comply; consensus was immediate, and in favor.

*tl;dr*: There will be some slight changes to the ZF2 coding standards soon so we can be PSR-1 and PSR-2 compliant.
<p>Currently, the only change this would require in the current ZF2 coding standards is to have a &quot;use&quot; statement <em>per</em> import (vs. a single &quot;use&quot; statement, with each import separated by commas). </p>

h3. Replacing the Plugin Broker + PluginClassLocator with ServiceManager
<p>There was no debate about whether or not we should comply; consensus was immediate, and in favor.</p>

(Search for "20:06:51" in the log.)
<p><strong>tl;dr</strong>: There will be some slight changes to the ZF2 coding standards soon so we can be PSR-1 and PSR-2 compliant.</p>

Matthew [raised a discussion on the ML|http://zend-framework-community.634137.n4.nabble.com/Proposal-replace-the-plugin-loader-with-the-service-manager-tp4655378.html] suggesting replacing plugin broker usage with context-specific service managers, and also posted a prototype. Since the plugin broker solution is a subset of the service manager, and currently allows injecting a service manager anyways, it seems reasonable to reduce the number of APIs in the framework and provide a more flexible solution.
<h3>Replacing the Plugin Broker + PluginClassLocator with ServiceManager</h3>

As Rob Allen (Akrabat) noted, "that's the one where we rip out code that noone uses and use the stuff we all have to use" -- less code, and an API everyone will be familiar with (as it's the core of the MVC).
<p>(Search for &quot;20:06:51&quot; in the log.)</p>

Just as in the PSR-1/PSR-2 discussion, there was immediate consensus in favor of taking this approach. (Update: Matthew already has a [pull request|https://github.com/zendframework/zf2/pull/1550] for this in place.)
<p>Matthew <a href="http://zend-framework-community.634137.n4.nabble.com/Proposal-replace-the-plugin-loader-with-the-service-manager-tp4655378.html">raised a discussion on the ML</a> suggesting replacing plugin broker usage with context-specific service managers, and also posted a prototype. Since the plugin broker solution is a subset of the service manager, and currently allows injecting a service manager anyways, it seems reasonable to reduce the number of APIs in the framework and provide a more flexible solution.</p>

*tl;dr*: plugin broker usage will be replaced with context-specific service managers in time for beta5.
<p>As Rob Allen (Akrabat) noted, &quot;that's the one where we rip out code that noone uses and use the stuff we all have to use&quot; &ndash; less code, and an API everyone will be familiar with (as it's the core of the MVC).</p>

h3. Documentation
<p>Just as in the PSR-1/PSR-2 discussion, there was immediate consensus in favor of taking this approach. (Update: Matthew already has a <a href="https://github.com/zendframework/zf2/pull/1550">pull request</a> for this in place.)</p>

(Search for "20:11:54" in the log.)
<p><strong>tl;dr</strong>: plugin broker usage will be replaced with context-specific service managers in time for beta5.</p>

Gary Hockin (Spabby) raised a discussion via the agenda suggesting we need to clean up documentation.
<h3>Documentation</h3>

Matthew noted that Jonas Marien has volunteered to refactor existing documentation not currently published to follow the new namespaces and class/interface/etc. renamings so that we at least have _some_ documentation in place. Additionally, his [RFC|Proposal for Documentation in ZF2] appears to have widespread agreement... but we don't have a plan for implementation.
<p>(Search for &quot;20:11:54&quot; in the log.)</p>

Rob Allen (Akrabat) reiterated that we need to do something radical with the documentation. Evan Coury (EvanDotPro) raised a concern that docbook may be a barrier to entry for many potential contributors.
<p>Gary Hockin (Spabby) raised a discussion via the agenda suggesting we need to clean up documentation.</p>

In the end, we realized we need a solid proposal for action. We agreed that Gary, Matthew, and Rob would collaborate to come up with such a proposal and present it to the community soon so we can start work.
<p>Matthew noted that Jonas Marien has volunteered to refactor existing documentation not currently published to follow the new namespaces and class/interface/etc. renamings so that we at least have <em>some</em> documentation in place. Additionally, his <ac:link><ri:page ri:content-title="Proposal for Documentation in ZF2" /><ac:link-body>RFC</ac:link-body></ac:link> appears to have widespread agreement... but we don't have a plan for implementation.</p>

*tl;dr*: In the short term, please help Jonas get current docs updated and in line with current code. If you have concrete ideas on how to improve documentation moving forward, including arguments for other documentation formats, please bring them up on the list.
<p>Rob Allen (Akrabat) reiterated that we need to do something radical with the documentation. Evan Coury (EvanDotPro) raised a concern that docbook may be a barrier to entry for many potential contributors.</p>

h3. Which components to ship?
<p>In the end, we realized we need a solid proposal for action. We agreed that Gary, Matthew, and Rob would collaborate to come up with such a proposal and present it to the community soon so we can start work.</p>

(Search for "20:21:15" in the log.)
<p><strong>tl;dr</strong>: In the short term, please help Jonas get current docs updated and in line with current code. If you have concrete ideas on how to improve documentation moving forward, including arguments for other documentation formats, please bring them up on the list.</p>

This topic was chaotic. Rob Allen (Akrabat) had posted to the mailing list last week a [list of components and current testing, packaging, and documentation status for each|http://zend-framework-community.634137.n4.nabble.com/Which-components-to-ship-td4655245.html], and has asked that we decide what will be in the stable version.
<h3>Which components to ship?</h3>

Unfortunately, there are a number of questions:
<p>(Search for &quot;20:21:15&quot; in the log.)</p>

* What do we do with any components we choose not to ship in the stable release? (i.e., do they all go in a separate repo? or a separate repo per component? or perhaps a separate branch on the zf2 repo? or simply delete and let folks pull from the history?
* What constitutes a stable component? Number of maintainers? Passing tests? Refactorization during Zf2 lifecycle?
<p>This topic was chaotic. Rob Allen (Akrabat) had posted to the mailing list last week a <a href="http://zend-framework-community.634137.n4.nabble.com/Which-components-to-ship-td4655245.html">list of components and current testing, packaging, and documentation status for each</a>, and has asked that we decide what will be in the stable version.</p>

Basically, we couldn't come to a consensus on any of these points.
<p>Unfortunately, there are a number of questions:</p>

We decided that Rob and Matthew will create a Google form with the list of components, current testing/documentation/packaging status, and known maintainers, and ask the community to vote on each. Additionally, we'll create a Google form or wiki poll presenting the various options for splitting out unstable components.
<ul>
<li>What do we do with any components we choose not to ship in the stable release? (i.e., do they all go in a separate repo? or a separate repo per component? or perhaps a separate branch on the zf2 repo? or simply delete and let folks pull from the history?</li>
<li>What constitutes a stable component? Number of maintainers? Passing tests? Refactorization during Zf2 lifecycle?</li>
</ul>

*tl;dr*: lots of polls in the community's future.

h2. Log
<p>Basically, we couldn't come to a consensus on any of these points.</p>

<p>We decided that Rob and Matthew will create a Google form with the list of components, current testing/documentation/packaging status, and known maintainers, and ask the community to vote on each. Additionally, we'll create a Google form or wiki poll presenting the various options for splitting out unstable components.</p>
{html:output=html}
<p><strong>tl;dr</strong>: lots of polls in the community's future.</p>

<h2>Log</h2>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<style>
pre.log {
20:32:54 &lt; Maks3w&gt; EvanDotPro, Seriously? s#Zend\Unstable\Component#Zend\Component
20:32:59 &lt;weierophinney&gt; WalterTamboer has a good point folks
20:33:10 &lt; cgmartin&gt; what issues are there for having a "unstable" branch and master (stable/deleted components)
20:33:10 &lt; mattcockayne&gt; just wanna clarify something i may have missed.. .are we suggesting 1 branch with all "unstable" components or on branch for each "unstable" component
20:33:12 &lt; Akrabat&gt; WalterTamboer: cos it's nearly impossible to work out what which components are which and what state they are in
20:58:13 &lt;weierophinney&gt; kk, let's call it a day, folks. Lots of action items. I'll get the SM stuff done by end of week so it can be in beta5
</pre>
{html}
]]></ac:plain-text-body></ac:macro>