Skip to end of metadata
Go to start of metadata



<p>The goal of is to provide a central repository and community site for Zend Framework 2 modules. This will help in the discovery of modules by users, and serve as the default module repository used by the ZF2 CLI.</p>

<h2>GitHub Integration</h2>

<p>Users should be able to register and sign in using their GitHub account. Utilizing the GitHub integration should be optional, but could offer some compelling features. For example, upon linking their GitHub acocunt, we could scan through a user's public repositories, and possibly even detect which repositories are ZF2 modules. We could then present them to the user, prompting them to choose which they'd like to publish. There are plenty of other GitHub integration points that could be leveraged, for example, if a module is hosted on GitHub, we could utilize their download URL's, etc. A module has been started for this purpose <a href="">here</a> (with the goal to integrate it with <a href="">EdpUser</a>).</p>

<h2>CLI Publishing</h2>

<p>The site should have some sort of API (JSON-RPC, REST, etc) to allow registration, authentication, and publishing of modules straight from the CLI, without having to visit the site. This idea comes from <a href="">Node.js' NPM</a>.</p>

<h2>Module Moderation and Review</h2>

<p>Developers should be free to publish their modules to the repository / site without being subject to initial moderation or approval. However, we should have mechanisms in place for users to report modules that are malicious, broken, otherwise buggy / insecure, or blatently disregard best practices. As a community, we can establish guidelines and/or requirements for inclusion in the main repository.</p>

<h3>Reviewed Module Seal</h3>

<p>One value-add we could offer is to put together a group of volunteers to review modules for things like best practices, security vulnerabilities, etc, and if everything checks out, we could flag the module with a seal indicating that it's been reviewed by the volunteer team. We would have to be VERY clear that this does not indicate ANY sort of waranty / guarantee / liability on part of the community or those who reviewed it, but rather just indicated that it has been looked over for conformance to some basic best practices. We would publish the "check list" used during the review of a module to determine if it qualifies for the seal.</p>


<p>It is proposed that we provide a list of acceptable open source licenses for a module's inclusion on the site and in the repository. This list can be determined by the community, but the primary focus should be primarily to prevent commercial / "trialware" type modules from polluting the repository. It will be easy for third parties to create and host their own repositories, so if there is a need for a commercial repository (think "app store" that handles payments, licensing, and all related logistics and liabilities), then that can be left to a third party developer or company that is willing to invest the resources required to take on such a burden. The focus of should be free and open source modules.</p>

<h2>Spectacular Example</h2>

<p>The site and the backend that runs it should be fully open source, and should serve as a spectacular example of a fully working ZF2 application. We should leverage existing community modules as much as possible, and when required, create additional re-usable modules if there is not already one to solve a specific problem. The project is already up on GitHub at <a href=""></a>.</p>

<p>Modules to consider: <a href="">SpiffyDoctrine</a>, <a href="">EdpUser</a>, <a href="">EdpGithub</a>.</p>

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 27, 2011

    <p>A little brainstorming....<br />
    <strong>What does matter for me (and maybe others) when it comes to a module</strong></p>
    <li>is the license commercial friendly or not - can I use it for my commercial app (i.e. GPL or BSD)</li>
    <li>when was the last commit/update (long abandoned modules are hard to maintain)</li>
    <li>how many users downloaded the module</li>
    <li>how many developers "like" the module (i.e. are using it, it solves their problems and they are happy <ac:emoticon ac:name="laugh" />)</li>
    <li>does it have any dependencies - maybe there is another module that uses the dependency that I¨m already using</li>
    <li>is it drop-in (not messing with my app)?</li>

    <p>Some or all of these things should be stored and provided for search/filtering, or at least seen from the list view. </p>

  2. Nov 27, 2011

    <p>Some other notes:</p>

    <li>Categorize and/or tag modules: this makes it easier to browse the complete module directory</li>
    <li>Search: based on name/author/maintainer/category/description</li>
    <li>Link to development site (eg the github repository)</li>
    <li>Know which versions are available (by default you see/download the latest, but other options possible too)</li>

    <p>I am not sure, but these could be options as well:</p>
    <li>A place to gather developers. An example is SensioLabs Connect where devs can earn badges</li>
    <li>A place to discuss, like a forum or something</li>
    <li>If we can make a pyrus channel as well, it can use the same installation process as zf2 itself</li>

  3. Nov 28, 2011

    <p>Some more notes:</p>

    <li>Add Markdown & Textile support</li>
    <li>Parse README files, if available (Maybe parse files in doc/docs folder, if any, to auto-generate Documentation)</li>
    <li>Get META information about the module, such as Author, Version, Repository URL, etc. whether from the Module class' DocBlock annotation or from an (optional) delivered composer.json file</li>
    <li>If a module is hosted on Github, use it's API to report Issues, so everything is right in place where it is developed, it would also be possible to provide META information about the author (and committers)</li>
    <li>Add comment functions to Modules</li>
    <li>(Add a process to search for volunteers - Someday someone doesn't want to maintain a module anymore, for this case there should be the possibility to transfer a project to another maintainer)</li>

    <p>As a later step:</p>

    <li>A place to raise issues and bug reports, something similar to what Github does, so the overall quality of modules should be increased (in addition to Githubs API features)</li>