View source for Manual:Developing libraries/es

<languages />
<span lang="en" dir="ltr" class="mw-content-ltr">These are guidelines for creating, publishing and managing libraries based on code originally developed as a part of MediaWiki or a related Wikimedia project.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Some of these are PHP-specific, but others are general and apply to all languages.</span>

<span id="Rationale"></span>
== Justificación ==
<span lang="en" dir="ltr" class="mw-content-ltr">There is a growing desire to separate useful libraries from the core MediaWiki application and make them usable in non-MediaWiki based projects.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This "''librarization''" of MediaWiki is thought to have several long term advantages:</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Make life better for new (and experienced) developers by organizing the code into simple components that can be easily understood.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Reverse inertia toward ever expanding monolithic core by encouraging developers (in core) to develop their work as reusable modules with clearly-defined interfaces
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Start making true unit testing of core viable by having individually-testable units
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Provide an interim step on the way to service-oriented architecture in a way that is useful independently of that goal
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Encourage reuse and integration with larger software ecosystem.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">Done correctly, this will provide a useful means of expanding our development capacity through recruitment of library authors eager to showcase their work on a top 10 website.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Share our awesome libraries with others and encourage contributions from them even if they aren't particularly interested in making our sites better.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">In order for this strategy to be successful, these libraries need to develop a life of their own, independent of MediaWiki.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Therefore, it will be important for library authors to have some latitude and independence in making the library successful.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The policies surrounding these should largely be dictated by the primary maintainer of the library, and the choices made may diverge from MediaWiki core.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Note that that primary maintainer may not be the original author of the majority of the code (or even any of it), and will have latitude to make independent decisions about the library.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The amount of latitude a maintainer gets is proportional to the amount of commitment, credibility and hard work with respect to the library they maintain.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Repository hosting guidelines ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Hosted in {{ll|Gerrit}} with GitHub mirror
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Hosted under the [https://github.com/wikimedia Wikimedia GitHub organization]
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Hosted under another GitHub organization
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Hosted in {{ll|Phabricator}} with GitHub mirror (?? are we ready to try [http://phabricator.org/applications/arcanist/ arc] out with libraries?)
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">The Wikimedia Foundation will likely invest in tooling that makes code review transfer from GitHub to internal review tools (Phabricator) in the future.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Eventually this should eliminate the difference between hosting the primary git repository with the Wikimedia Foundation or GitHub.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">In the near term, Gerrit hosting is the default hosting option except in cases where an effort is being made to attract a significant portion of contributions from external developers.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">Don't host under an individual user's GitHub account.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">It complicates code review based on pull requests for the repository owner and makes management of the repository by a shared group difficult.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Note: this doesn't mean it has to be hosted under the Wikimedia account specifically; in fact, it can be more convenient to have the project under a different organizational account specific to the project, like [https://github.com/cssjanus CSSJanus].</span>

<span id="Repository_naming_guidelines"></span>
== Directrices de nomenclatura de repositorios ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Probably varies somewhat based on hosting location.
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">Follow the local conventions as far as reasonable and possible.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Do not add "wikimedia-" prefixes to repository names.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
On Gerrit the Git repository should be named "mediawiki/libs/&lt;name>".
</div>

<span id="Issue_tracking_guidelines"></span>
== Directrices de seguimiento de incidencias ==

* Phabricator
* GitHub

<span lang="en" dir="ltr" class="mw-content-ltr">Your library's issue tracking should match your git hosting, in order to reduce the friction of matching commits and pull requests to issues and vice versa.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Thus Gerrit-hosted repos should [[Special:MyLanguage/Phabricator|Wikimedia's Phabricator instance]] and GitHub-hosted repos should use GitHub's built-in issue tracker.</span>

<span id="Code_review_guidelines"></span>
== Directrices de revisión de código ==
<span lang="en" dir="ltr" class="mw-content-ltr">Project code review should use the tool most closely associated with the primary git hosting.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Regardless of choice of hosting platform, pre-merge code review and unit testing are strongly encouraged.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Blatant self-merge behavior should be seen just as distasteful on GitHub as it generally is in Gerrit.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">If primary hosting is via GitHub, changes should be proposed via pull requests rather than direct push to master.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">In most cases the pull requests should originate from a fork of the repository associated with the user's own GitHub account.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">[http://gerrithub.io GerritHub] is a Gerrit powered code review service that can be used with GitHub hosted repositories for projects that want to use Gerrit but for some reason do not want to host with Wikimedia.</span>

<span id="Code_style_guidelines"></span>
<div class="mw-translate-fuzzy">
== Directrices de estilo de código ==
</div>
{{See also|Special:MyLanguage/Continuous integration/Entry points#Testing PHP|label 1=<span lang="en" dir="ltr" class="mw-content-ltr">Continuous integration/Entry points#Testing PHP</span>}}

<div lang="en" dir="ltr" class="mw-content-ltr">
We encourage [[Special:MyLanguage/Manual:Coding conventions|MediaWiki style]] or [http://www.php-fig.org/psr/psr-2/ PHP PSR-2], but the most important things are clarity, consistency, and best likelihood of adoption by the library's developer community.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">When creating a new repository, you MUST choose a coding style standard and enforce it with CodeSniffer.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Also point to the style guide in the project's README file.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
For the MediaWiki coding style, use the [//packagist.org/packages/mediawiki/mediawiki-codesniffer mediawiki/mediawiki-codesniffer] package.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">Be sure to use the latest version of mediawiki-codesniffer (check [https://packagist.org/packages/mediawiki/mediawiki-codesniffer packagist.org]).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Don't use a wildcard version, upgrades must be done explicitly to prevent a non-passing state of the master branch.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
For the PSR-2 coding style, use [https://packagist.org/packages/squizlabs/php_codesniffer PHP CodeSniffer].
</div>

<span id="Automated_testing_guidelines"></span>
== Directrices de pruebas automatizadas ==
<span lang="en" dir="ltr" class="mw-content-ltr">Both pre and post-merge testing should be used.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The testing should include basic lint, unit tests and coding style checks.</span>

=== Gerrit ===
<span lang="en" dir="ltr" class="mw-content-ltr">Projects hosted in Wikimedia Gerrit should use Jenkins.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Use the <code>composer test</code> entry point.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">See [[Special:MyLanguage/Continuous integration/Entry points#PHP|Continuous integration/Entry points#PHP]] for details.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">Once created, be sure to also enable the post-merge publisher for automatically generating documentation and code coverage (e.g. for IPSet, https://doc.wikimedia.org/IPSet/ and https://doc.wikimedia.org/cover/IPSet/).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">These jobs can be enabled for your project in the <code>integration/config</code> repository (example commit: {{gerrit|227615}}).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Alternatively, file a task in [[phab:tag/ci-config/|the #ci-config project]].</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Packagist guidelines ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
PHP libraries should be published on [https://packagist.org/ packagist.org]. When adding new packages:
</div>

* <span lang="en" dir="ltr" class="mw-content-ltr">Follow the [[Special:MyLanguage/Manual:Composer.json best practices|composer.json best practices]] and add one to your repository.</span>
* Request the [https://packagist.org/about Packagist.org service hook] in the GitHub repo to be configured by [https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=librarization&subscribers=Reedy,bd808,Krinkle,legoktm&title=Set%20up%20Packagist%20webhook%20for%20%3CLIBRARY%3E&description=Github%20URL:%20%3CURL%3E filing a task].

<div lang="en" dir="ltr" class="mw-content-ltr">
Instructions if you have the required permissions (you are an [https://github.com/orgs/wikimedia/people owner in the Wikimedia GitHub organization] and have access to the <code>mediawiki</code> and <code>wikimedia</code> Packagist accounts):
</div>

# <span lang="en" dir="ltr" class="mw-content-ltr">Use the github.com mirror as the git url, this will allow composer to download zipballs which can be cached.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Submit the repo to Packagist.org:
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
#* Log in to Packagist.org with the wikimedia account and submit the GitHub url.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Ensure both the "mediawiki" and "wikimedia" accounts are maintainer of the package.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The following people have access to the different accounts in case a package needs to be updated for any reason:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* '''wikimedia''': [[User:BDavis (WMF)|BDavis]], [[User:Krinkle|Krinkle]] ...? (credentials kept in the [[Special:MyLanguage/Wikimedia Site Reliability Engineering|SRE]] team [[wikitech:Pwstore|pwstore]])
* '''mediawiki''': [[User:^demon|^demon]], [[User:Legoktm|Legoktm]], [[User:BDavis (WMF)|BDavis]], [[User:Krinkle|Krinkle]] ...? (credentials kept in the [[Special:MyLanguage/Wikimedia Site Reliability Engineering|SRE]] team [[wikitech:Pwstore|pwstore]])
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">Packages distributed via Composer and Packagist should also include a <code>.gitattributes</code> configuration file in their git repository which excludes files such as tests and examples which are not needed at runtime from the generated package.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The wikimedia/RelPath library is a good example:</span>

<pre>
/.* export-ignore
/Doxyfile export-ignore
/composer.json export-ignore
/phpunit.xml.dist export-ignore
/build/ export-ignore
/tests/ export-ignore
</pre>

<span lang="en" dir="ltr" class="mw-content-ltr">Note that composer.json should be excluded which is a bit counterintuitive.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The actual composer.json matching a given release of your library will be generated by Packagist and sent outside of the actual zip package.</span>

<span id="License_guidelines"></span>
== Directrices de licencia ==
<span lang="en" dir="ltr" class="mw-content-ltr">For almost anything that gets extracted from MediaWiki, it's likely that it will need to be GPLv2 (or later).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">'''All''' contributors must agree to a change of license from GPLv2+ in order for anyone to change the license (other than changing to GPLv3).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The license of the new library needs to remain clearly marked in the headers of the code, and the full license file (typically called "LICENSE" or "COPYING") must be carried into the new project.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">For a library consisting entirely of new code any license complying with the [http://opensource.org/osd Open Source Definition] is likely to be acceptable, but the [http://opensource.org/licenses/MIT MIT], [http://opensource.org/licenses/gpl-license GPLv2+] and [http://www.apache.org/licenses/LICENSE-2.0 Apache License 2.0] licenses may be the easiest to adopt.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Include both contributor copyright grant clauses which are important for ensuring the integrity of the project's code base.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The Apache2 and MIT licenses are seen as more ''permissive,'' in that it allows derivative works to include a separate license for new contributions.</span>

<span id="Documentation_guidelines"></span>
== Directrices de documentación ==

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Readme ===
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">Any library should have a README.md file that describes the project at a high level.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This file should be formatted using [http://daringfireball.net/projects/markdown/ Markdown] syntax (e.g. for headers, links, and code blocks) which is commonly supported by the majority of git browsers while also being human readable.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
A good README.md will include:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* A brief description of the primary use case the library solves
* How to install the library
* How to use the library (prose and brief code example if possible)
* How to contribute
** License name (GPL-2, ...)
** Where to submit bugs
** Where to submit patches
** Link to coding standard
** How to run tests
** Where to see automated test results
</div>

<span id="Code_documentation"></span>
=== Documentación del código ===

<div lang="en" dir="ltr" class="mw-content-ltr">
Add a pipeline for generating code documentation. Common choices are:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* {{ll|Doxygen}} (for PHP)
* {{ll|JSDuck}} (for JavaScript)
* Sphinx (for Python)
* Yard (for Ruby)
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">View existing libraries' documentation at https://doc.wikimedia.org for an example of what these look like.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">See [[Special:MyLanguage/Continuous integration/Entry points|Continuous integration/Entry points]] for how to configure these.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== On-wiki documentation ===
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">Libraries should have a brief page on mediawiki.org documenting their purpose, history, and related links.</span>
Ejemplos ([[Developers/Maintainers#Libraries|lista completa]]):
* {{ll|CDB}}
* {{ll|utfnormal}}
* {{ll|IPSet}}

<div lang="en" dir="ltr" class="mw-content-ltr">
== Bootstrapping a new library ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">New libraries require a lot of different common files to boostrap the library (.gitattributes, composer.json, Doxyfile, phpunit.xml, etc.).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">To make this easier there are tools that will bootstrap the extension for you.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
* PHP libraries: [[phab:diffusion/MCCL/|cookiecutter-library]]
</div>

<span id="Common_combinations"></span>
== Combinaciones comunes ==

<div lang="en" dir="ltr" class="mw-content-ltr">
* Hosted in Gerrit and published to Packagist under the <code>wikimedia</code> namespace
* Hosted in the Wikimedia GitHub organization and published to Packagist under the <code>wikimedia</code> namespace
* Hosted in another GitHub organization and published to Packagist as something other than wikimedia or mediawiki (e.g. cssjanus).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When hosting is in Gerrit the project should run as any other "typical" Wikimedia sponsored project with Gerrit code review, Phabricator bug tracking and wiki documentation.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">If hosted at GitHub the project could reasonably choose to do code review via pull requests and host the bug tracker on GitHub.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This choice should be considered carefully on a project by project basis as divergence of code review and issue tracking tools from the larger Wikimedia community has some disadvantages:</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
* The {{ll|Bugwrangler}} will not be expected to monitor your project for issues.
* Members of the MediaWiki developer community will probably file bugs against your product in Phabricator anyway.
* Moving a bug report between your project and MediaWiki will be a more involved process.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
These downsides may diminish over time if better bots can be created to integrate between the two environments.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">Hosting under an independent GitHub organization makes sense for certain projects (CSSJanus, Wikidata, Semantic MediaWiki, ...) where an effort is being made to develop an independent and sustaining community for the project.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">It is especially reasonable in the case of a library like CSSJanus that is attempting to establish a cross-community and cross-language standard set of tools where only a portion of the tools overlap with the Wikimedia universe.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Transferring an existing GitHub repo to Wikimedia ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* File a ticket in the <span class="plainlinks">[//phabricator.wikimedia.org/maniphest/task/create?projects=Librarization&title=GitHub+transfer:&priority=50 Phabricator Librarization]</span> project requesting transfer.
* When contacted, transfer the repository to the responding Wikimedia GitHub administrator.
* The administrator will move the project to Wikimedia and give you access.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Tips for extracting a library ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">The details of extracting a library will vary depending on the code being extracted and its current entanglement with other MediaWiki specific classes.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">In the best case, the code you want to extract is already contained in the <code>includes/libs</code> directory of mediawiki/core.git and thus completely unencumbered.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">It is suggested that code which is not in this state is progressively updated and refactored until that is the case.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
Once you get all the code into <code>includes/libs</code>, things become a little more straight forward:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Create a new project following the rest of the guidelines in this RFC.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Import the code from <code>includes/libs</code> into your new project<ref>[[gerrit:172312]]</ref>.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
#* It may be possible to use <code>git filter-branch</code> to extract a copy of the files with commit history preserved, but that is not currently considered a prerequisite for extraction.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">It should be sufficient to take the current head of the files into the new project and provide documentation of the file provenance in the new project's README<ref>[//github.com/wikimedia/cdb#history github.com/wikimedia/cdb#history]</ref>.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Create a proper <code>composer.json</code> file that follows [[Special:MyLanguage/Manual:composer.json best practices|best practices]] for the project and publish to Packagist<ref>[https://packagist.org/packages/wikimedia/cdb wikimedia/cdb at Packagist]</ref>.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Tag the repository to create a stable release.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Propose a change to <code>mediawiki/vendor.git</code> importing the stable release of your new project<ref>[[gerrit:172793]]</ref>.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">See {{ll|Manual:External libraries}} for additional details.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Propose a change to <code>composer.json</code> in <code>mediawiki/core.git</code> to require the stable release of your new project<ref>[[gerrit:172779]]</ref>.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">It may also be necessary to introduce shim classes <code>mediawiki/core.git</code> to provide a backwards compatible bridge between your extracted library and the existing MediaWiki code base.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The {{ll|CDB}} library did this to provide backwards-compatible class names which did not require the use of the new <code>Cdb\</code> namespace<ref>[[gerrit:172779]]</ref>.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Tagging a release ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* When determining the next version number, stick to [http://semver.org/ semantic versioning]
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* GPG sign the tag by adding <code>-s</code> to the <code>git tag</code> command
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* You may also want to provide a changelog in the annotated tag notes
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Then <code>git push --tags</code> to submit the tag.
</div>

<span id="After_the_first_release"></span>
== Luego del primer lanzamiento ==
<span lang="en" dir="ltr" class="mw-content-ltr">Once the repository is bootstrapped and the initial release has been made.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Here's a few next moves to consider:</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Create a page for the library here on mediawiki.org.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">See {{ll|at-ease}} for a good example.</span> <span lang="en" dir="ltr" class="mw-content-ltr">This page should point to:</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
** Source code (e.g. git.wikimedia.org, or github.com).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** Published package (e.g. on Packagist.org or npmjs.org).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** Issue tracker (e.g. Phabricator workboard, or GitHub Issues).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** API Documentation (e.g. doc.wikimedia.org).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Enter description and URL for GitHub mirror.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">Especially if it's only mirrored to GitHub, this is easy to forget.</span> <span lang="en" dir="ltr" class="mw-content-ltr">Enter a one-line description and enter the url to the mediawiki.org page (if it exists) or else the doc.wikimedia.org page.</span> <span lang="en" dir="ltr" class="mw-content-ltr">See https://github.com/wikimedia/cdb and https://github.com/wikimedia/oojs for examples.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== RFC information ==
</div>

{{RFC
| created = 2014-12-24
| authors = {{U|BDavis (WMF)}}
| decision = Accepted. [[User:Tim Starling|Tim Starling]] ([[User talk:Tim Starling|talk]]) 21:45, 14 Jan 2015 (UTC)
| status = implemented
}}
<span lang="en" dir="ltr" class="mw-content-ltr">This originated as a '''request for comment''', "Guidelines for extracting, publishing and managing libraries".</span>
<span lang="en" dir="ltr" class="mw-content-ltr">[http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20150114.txt The decision] was to move this page out of the RFC space and improve it as documentation.</span>
{{clear}}

<span id="See_also"></span>
== Véase también ==
* {{ll|Manual:Composer.json best practices}}
<div lang="en" dir="ltr" class="mw-content-ltr">
* [[Requests_for_comment/Composer_managed_libraries_for_use_on_WMF_cluster|Composer managed libraries for use on WMF cluster RFC]]
</div>
* {{ll|Library infrastructure for MediaWiki}}
<div lang="en" dir="ltr" class="mw-content-ltr">
* [[phab:tag/Librarization|Librarization project]] in Phabricator
</div>
* [[Special:MyLanguage/Continuous integration/Entry points|<span lang="en" dir="ltr" class="mw-content-ltr">Continuous integration/Entry points</span>]]

<span id="References"></span>
== Referencias ==
<references/>

[[Category:Composer{{#translation:}}]]
[[Category:MediaWiki development{{#translation:}}]]
[[Category:Libraries{{#translation:}}| ]]
[[Category:PHP libraries{{#translation:}}| ]]