Merge "[cycle-goals] Add PTL and contributor quickstart"
This commit is contained in:
Zuul
Gerrit Code Review
commit
301789f9be
|
|
@ -1,19 +1,23 @@
|
|||
If you would like to contribute to the development of OpenStack,
|
||||
you must follow the steps in this page:
|
||||
The source repository for this project can be found at:
|
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html
|
||||
https://opendev.org/openstack/manila
|
||||
|
||||
Once those steps have been completed, changes to OpenStack
|
||||
should be submitted for review via the Gerrit tool, following
|
||||
the workflow documented at:
|
||||
This repository is mirrored to GitHub at:
|
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html#development-workflow
|
||||
https://github.com/openstack/manila
|
||||
|
||||
Pull requests submitted through GitHub will be ignored.
|
||||
Pull requests submitted through GitHub are not monitored.
|
||||
|
||||
Bugs should be filed on Launchpad, not GitHub:
|
||||
To start contributing to OpenStack, follow the steps in the contribution guide
|
||||
to set up and use Gerrit:
|
||||
|
||||
https://docs.openstack.org/contributors/code-and-documentation/quick-start.html
|
||||
|
||||
Bugs should be filed on Launchpad:
|
||||
|
||||
https://bugs.launchpad.net/manila
|
||||
|
||||
For more specific information about contributing to this repository, see the
|
||||
Manila contributor guide:
|
||||
|
||||
|
||||
https://docs.openstack.org/manila/latest/contributor/contributing.html
|
||||
|
|
|
|||
|
|
@ -0,0 +1,270 @@
|
|||
============================
|
||||
So You Want to Contribute...
|
||||
============================
|
||||
|
||||
For general information on contributing to OpenStack, check out the
|
||||
`contributor guide <https://docs.openstack.org/contributors/>`_ to get started.
|
||||
It covers all the basics that are common to all OpenStack projects: the
|
||||
accounts you need, the basics of interacting with our Gerrit review system,
|
||||
how we communicate as a community, etc.
|
||||
|
||||
Below will cover the more project specific information you need to get started
|
||||
with Manila (Shared File System service).
|
||||
|
||||
|
||||
Where is the code?
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
manila
|
||||
| The OpenStack Shared File System Service
|
||||
| code: https://opendev.org/openstack/manila
|
||||
| docs: https://docs.openstack.org/manila/
|
||||
| api-ref: https://docs.openstack.org/api-ref/shared-file-system
|
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc
|
||||
| Launchpad: https://launchpad.net/manila
|
||||
|
||||
|
||||
python-manilaclient
|
||||
| Python client library for the OpenStack Shared File System Service API;
|
||||
includes standalone CLI shells and OpenStack client plugin and shell
|
||||
| code: https://opendev.org/openstack/python-manilaclient
|
||||
| docs: https://docs.openstack.org/python-manilaclient
|
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary
|
||||
| Launchpad: https://launchpad.net/python-manilaclient
|
||||
|
||||
|
||||
manila-ui
|
||||
| OpenStack dashboard plugin for the Shared File System Service
|
||||
| code: https://opendev.org/openstack/manila-ui
|
||||
| docs: https://docs.openstack.org/manila-ui
|
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary
|
||||
| Launchpad: https://launchpad.net/manila-ui
|
||||
|
||||
|
||||
manila-tempest-plugin
|
||||
| An OpenStack test integration (tempest) plugin containing API and
|
||||
scenario tests for the Shared File System Service
|
||||
| code: https://opendev.org/openstack/manila-tempest-plugin
|
||||
| release model: https://releases.openstack.org/reference/release_models.html#cycle-automatic
|
||||
| Launchpad: https://launchpad.net/manila
|
||||
|
||||
|
||||
manila-image-elements
|
||||
| A Disk Image Builder project with scripts to build a bootable Linux
|
||||
image for testing and use by some Shared File System Service storage
|
||||
drivers including the Generic Driver
|
||||
| code: https://opendev.org/openstack/manila-tempest-plugin
|
||||
| release model: no releases
|
||||
| Launchpad: https://launchpad.net/manila
|
||||
|
||||
|
||||
manila-test-image
|
||||
| A project with scripts to create a Buildroot based image to create a
|
||||
small bootable Linux image, primarily for the purposes of testing Manila
|
||||
| code: https://opendev.org/openstack/manila-image-elements
|
||||
| images: https://tarballs.opendev.org/openstack/manila-image-elements/
|
||||
| release model: no releases
|
||||
| Launchpad: https://launchpad.net/manila-image-elements
|
||||
|
||||
|
||||
manila-specs
|
||||
| Design Specifications for the Shared File System service
|
||||
| code: https://opendev.org/openstack/manila-specs
|
||||
| release model: no releases
|
||||
| Launchpad: https://launchpad.net/manila
|
||||
|
||||
|
||||
See the ``CONTRIBUTING.rst`` file in each code repository for more
|
||||
information about contributing to that specific deliverable. Additionally,
|
||||
you should look over the docs links above; most components have helpful
|
||||
developer information specific to that deliverable.
|
||||
|
||||
Manila and its associated projects follow a coordinated release alongside
|
||||
other OpenStack projects. Development cycles are code named. See the
|
||||
`OpenStack Releases website`_ for names and schedules of the current, past
|
||||
and future development cycles.
|
||||
|
||||
|
||||
Communication
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
IRC
|
||||
---
|
||||
|
||||
The team uses `IRC <https://docs.openstack.org/contributors/common/irc.html>`_
|
||||
extensively for communication and coordination of project activities. The
|
||||
IRC channel is ``#openstack-manila`` on Freenode. Contributors work in various
|
||||
timezones across the world; so many of them run IRC Bouncers and appear to be
|
||||
always online. If you ping someone, or raise a question on the IRC channel,
|
||||
someone will get back to you when they are back on their computer.
|
||||
Additionally, the IRC channel is logged, so if you ask a question
|
||||
when no one is around, you can `check the log
|
||||
<http://eavesdrop.openstack.org/irclogs/%23openstack-manila/>`_
|
||||
to see if it has been answered.
|
||||
|
||||
|
||||
Team Meetings
|
||||
-------------
|
||||
We host a one-hour IRC based community meeting every Thursday at 1500
|
||||
UTC on ``#openstack-meeting-alt`` channel. See the `OpenStack meetings page
|
||||
<http://eavesdrop.openstack.org/#Manila_Team_Meeting>`_ for the most
|
||||
up-to-date meeting information and for downloading the ICS file to integrate
|
||||
this slot with your calendar. The community meeting is a good opportunity to
|
||||
gather the attention of multiple contributors synchronously. If you wish to
|
||||
do so, add a meeting topic along with your IRC nick to the
|
||||
`Meeting agenda <https://wiki.openstack.org/wiki/Manila/Meetings>`_.
|
||||
|
||||
Mailing List
|
||||
------------
|
||||
|
||||
In addition to IRC, the team uses the `OpenStack Discuss Mailing List`_
|
||||
for development discussions. This list is meant for communication
|
||||
about all things developing OpenStack; so we also use this list to engage with
|
||||
contributors across projects, and make any release cycle announcements.
|
||||
Since it is a wide distribution list, the use of subject line tags is
|
||||
encouraged to make sure you reach the right people. Prefix the
|
||||
subject line with ``[manila]`` when sending email that concern Manila on
|
||||
this list.
|
||||
|
||||
|
||||
Other Communication Avenues
|
||||
---------------------------
|
||||
|
||||
Contributors gather at least once per release at the `OpenDev Project Team
|
||||
Gathering <https://www.openstack.org/ptg>`_ to discuss plans for an upcoming
|
||||
development cycle. This is usually where developers pool ideas and
|
||||
brainstorm features and bug fixes. We have had both virtual, and in-person
|
||||
Project Technical Gathering events in the past. Before every such event, we
|
||||
gather opinions from the community via IRC Meetings and the Mailing list on
|
||||
planning these Project Technical Gatherings.
|
||||
|
||||
We make extensive use of `Etherpads <https://etherpad.opendev.org>`_. You can
|
||||
find some of them that the team used in the past `in the project Wiki
|
||||
<https://wiki.openstack.org/wiki/Manila/Etherpads>`_. To share code
|
||||
snippets or logs, we use `PasteBin <http://paste.openstack.org>`_.
|
||||
|
||||
.. _contacting-the-core-team:
|
||||
|
||||
Contacting the Core Team
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you contribute patches, your change will need to be approved by one or
|
||||
more `maintainers (collectively known as the "Core Team")
|
||||
<https://wiki.openstack.org/wiki/Manila#People>`_.
|
||||
|
||||
We're always looking for more maintainers! If you're looking to help
|
||||
maintain Manila, express your interest to the existing core team. We have
|
||||
mentored many individuals for one or more development cycles and added them to
|
||||
the core team.
|
||||
|
||||
Any new core reviewer needs to be nominated to the team by an existing core
|
||||
reviewer by making a proposal on `OpenStack Discuss Mailing List`_. Other
|
||||
maintainers and contributors can then express their approval or disapproval
|
||||
by responding to the proposal. If there is a decision, the project team lead
|
||||
will add the concerned individual to the core reviewers team. An example
|
||||
proposal is `here.
|
||||
<http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012677.html>`_
|
||||
|
||||
|
||||
New Feature Planning
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you'd like to propose a new feature, do so by `creating a blueprint
|
||||
on Launchpad. <https://blueprints.launchpad.net/manila>`_ For significant
|
||||
changes we might require a design specification.
|
||||
|
||||
Feature changes that need a specification include:
|
||||
--------------------------------------------------
|
||||
|
||||
- Adding new API methods
|
||||
- Substantially modifying the behavior of existing API methods
|
||||
- Adding a new database resource or modifying existing resources
|
||||
- Modifying a share back end driver interface, thereby affecting all share
|
||||
back end drivers
|
||||
|
||||
What doesn't need a design specification:
|
||||
-----------------------------------------
|
||||
|
||||
- Making trivial (backwards compatible) changes to the behavior of an
|
||||
existing API method. Examples include adding a new field to the response
|
||||
schema of an existing method, or introducing a new query parameter. See
|
||||
:doc:`api_microversion_dev` on how Manila APIs are versioned.
|
||||
- Adding new share back end drivers or modifying share drivers, without
|
||||
affecting the share back end driver interface
|
||||
- Adding or changing tests
|
||||
|
||||
After filing a blueprint, if you're in doubt whether to create a design
|
||||
specification, contact the maintainers.
|
||||
|
||||
Design specifications are tracked in the `Manila
|
||||
Specifications <https://opendev.org/openstack/manila-specs>`_ repository and
|
||||
are published on the `OpenStack Project Specifications website.
|
||||
<https://specs.openstack.org/openstack/manila-specs/>`_ Refer to the
|
||||
`specification template
|
||||
<https://specs.openstack.org/openstack/manila-specs/specs/template.html>`_
|
||||
to structure your design spec.
|
||||
|
||||
Specifications and new features have deadlines. Usually, specifications for
|
||||
an upcoming release are frozen midway into the release development
|
||||
cycle. To determine the exact deadlines, see the published release calendars
|
||||
by navigating to the specific release from the `OpenStack releases website`_.
|
||||
|
||||
|
||||
Task Tracking
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
- We track our bugs in Launchpad:
|
||||
|
||||
https://bugs.launchpad.net/manila
|
||||
|
||||
If you're looking for some smaller, easier work item to pick up and get
|
||||
started on, search for the 'low-hanging-fruit' tag
|
||||
|
||||
- We track future features as blueprints on Launchpad:
|
||||
|
||||
https://blueprints.launchpad.net/manila
|
||||
|
||||
- Unimplemented specifications are tracked here:
|
||||
|
||||
https://specs.openstack.org/openstack/manila-specs/#unimplemented-specs
|
||||
|
||||
These specifications need a new owner. If you're interested to pick them
|
||||
up and drive them to completion, you can update the corresponding blueprint
|
||||
and get in touch with the project maintainers for help
|
||||
|
||||
|
||||
Reporting a Bug
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
You found an issue and want to make sure we are aware of it? You can do so on
|
||||
`Launchpad <https://bugs.launchpad.net/manila>`_.
|
||||
|
||||
Getting Your Patch Merged
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you submit your change through Gerrit, a number of automated Continuous
|
||||
Integration tests are run on your change. A change must receive a +1 vote
|
||||
from the `OpenStack CI system <https://zuul.opendev.org/t/openstack/status>`_
|
||||
in order for it to be merge-worthy. If these tests are failing and you can't
|
||||
determine why, contact the maintainers.
|
||||
|
||||
See the :doc:`manila-review-policy` to understand our code review
|
||||
conventions. Generally, reviewers look at new code submissions pro-actively;
|
||||
if you do not have sufficient attention to your change, or are looking for
|
||||
help, do not hesitate to jump into the team's IRC channel, or bring our
|
||||
attention to your issue during a community meeting. The core team would
|
||||
prefer to have an open discussion instead of a one-on-one/private chat.
|
||||
|
||||
|
||||
Project Team Lead Duties
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A `project team lead <https://docs.openstack.org/project-team-guide/ptl.html>`_
|
||||
is elected from the project contributors each cycle. Manila Project specific
|
||||
responsibilities for a lead are listed in the :doc:`project-team-lead`.
|
||||
|
||||
|
||||
.. _OpenStack Releases website: <https://releases.openstack.org>
|
||||
.. _OpenStack Discuss Mailing List: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
.. _Manila Project Team Lead guide: ../project-team-lead.rst
|
||||
.. _API Microversions: ../api_microversion_dev.rst
|
||||
|
|
@ -21,6 +21,15 @@ Contributor/Developer Guide
|
|||
In this section you will find information helpful for contributing to manila.
|
||||
|
||||
|
||||
Basic Information
|
||||
-----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
contributing
|
||||
|
||||
|
||||
Programming HowTos and Tutorials
|
||||
--------------------------------
|
||||
.. toctree::
|
||||
|
|
@ -59,6 +68,7 @@ Other Resources
|
|||
launchpad
|
||||
gerrit
|
||||
manila-review-policy
|
||||
project-team-lead
|
||||
|
||||
API Reference
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,205 @@
|
|||
..
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
not use this file except in compliance with the License. You may obtain
|
||||
a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
Manila Project Team Lead guide
|
||||
==============================
|
||||
|
||||
A `project team lead <https://docs.openstack.org/project-team-guide/ptl.html>`_
|
||||
for Manila is elected from the project contributors. A candidate for PTL
|
||||
needn't be a core reviewer on the team, but, must be a contributor,
|
||||
and be familiar with the project to lead the project through
|
||||
its release process. If you would like to be a core reviewer begin by
|
||||
:ref:`contacting-the-core-team`. All the responsibilities below help us in
|
||||
maintaining the project. A project team lead can perform any of these or
|
||||
delegate tasks to other contributors.
|
||||
|
||||
General Responsibilities
|
||||
------------------------
|
||||
|
||||
* Ensure manila meetings have a chair
|
||||
|
||||
* https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/manila-team-meeting.yaml
|
||||
|
||||
* Update the team people wiki
|
||||
|
||||
* https://wiki.openstack.org/wiki/Manila#People
|
||||
|
||||
|
||||
Release cycle activities
|
||||
------------------------
|
||||
|
||||
* Get acquainted with the release schedule and set Project specific
|
||||
milestones in the `OpenStack Releases repository
|
||||
<https://opendev.org/openstack/releases>`_
|
||||
|
||||
* Example: https://releases.openstack.org/victoria/schedule.html
|
||||
|
||||
* Ensure the Manila `Cross Project Liaisons
|
||||
<https://wiki.openstack.org/wiki/CrossProjectLiaisons>`_ are aware of
|
||||
their duties and are plugged into the respective areas
|
||||
|
||||
* Acknowledge `community wide cycle goals
|
||||
<https://governance.openstack.org/tc/goals/#community-goals>`_ and find
|
||||
leaders and coordinate with the goal liaisons
|
||||
|
||||
* Plan team activities such as:
|
||||
|
||||
* ``Documentation day/s`` to groom documentation bugs and re-write
|
||||
release cycle docs
|
||||
* ``Bug Triage day/s`` to ensure the bug backlog is well groomed
|
||||
* ``Bug Squash day/s`` to close bugs
|
||||
* ``Collaborative Review meeting/s`` to perform a high-touch review of a code
|
||||
submission over a synchronous call
|
||||
|
||||
* Milestone driven work:
|
||||
|
||||
* ``Milestone-1``:
|
||||
|
||||
- Request a release for the python-manilaclient and manila-ui
|
||||
- Retarget any bugs whose fixes missed Milestone-1
|
||||
|
||||
* ``Milestone-2``:
|
||||
|
||||
- Retarget any bugs whose fixes missed Milestone-2
|
||||
- Create a review priority etherpad and share it with the community
|
||||
and have reviewers sign up
|
||||
|
||||
* ``Milestone-3``:
|
||||
|
||||
- Groom the release notes for python-manilaclient and add a 'prelude'
|
||||
section describing the most important changes in the release
|
||||
- Request a final cycle release for python-manilaclient
|
||||
- Retarget any bugs whose fixes missed Milestone-3
|
||||
- Grant/Deny any Feature Freeze Exception Requests
|
||||
- Update task trackers for Community Wide Goals
|
||||
- Write the cycle-highlights in marketing-friendly sentences
|
||||
and propose to the openstack/releases repo. Usually based on reno
|
||||
prelude but made more readable and friendly
|
||||
|
||||
* Example: https://review.opendev.org/717801/
|
||||
|
||||
- Create the launchpad series and milestones for the next cycle in
|
||||
manila, python-manilaclient and manila-ui. Examples:
|
||||
|
||||
* manila: https://launchpad.net/manila/ussuri
|
||||
* python-manilaclient: https://launchpad.net/python-manilaclient/ussuri
|
||||
* manila-ui: https://launchpad.net/manila-ui/ussuri
|
||||
|
||||
* ``Before RC-1``:
|
||||
|
||||
- Groom the release notes for manila-ui and add a 'prelude'
|
||||
section describing the most important changes in the release
|
||||
- Request a final cycle release for manila-ui
|
||||
- Groom the release notes for manila, add a 'prelude' section
|
||||
describing the most important changes in the release
|
||||
- Mark bugs as {release}-rc-potential bugs in launchpad, ensure they
|
||||
are targeted and addressed by RC
|
||||
|
||||
* ``RC-1``:
|
||||
|
||||
- Request a RC-1 release for manila
|
||||
- Request a final cycle tagged release for manila-tempest-plugin
|
||||
- Ensure all blueprints for the release have been marked "Implemented"
|
||||
or are re-targeted
|
||||
|
||||
* ``After RC-1``:
|
||||
|
||||
- Close the currently active series on Launchpad for manila,
|
||||
python-manilaclient and manila-ui and set the "Development Focus"
|
||||
to the next release. Alternatively, you can switch this on the
|
||||
series page by setting the next release to “active development”
|
||||
- Set the last series status in each of these projects to “current
|
||||
stable branch release”
|
||||
- Set the previous release's series status to “supported”
|
||||
- Move any Unimplemented specs in `the specs repo
|
||||
<https://opendev.org/openstack/manila-specs>`_ to "Unimplemented"
|
||||
- Create a new specs directory in the specs repo for the next
|
||||
cycle so people can start proposing new specs
|
||||
|
||||
* You should NOT plan to have more than one RC. RC2 should only happen
|
||||
if there was a mistake and something was missed for RC-1, or a new regression
|
||||
was discovered
|
||||
|
||||
* Periodically during the release:
|
||||
|
||||
* ``Every Week``:
|
||||
|
||||
- Coordinate the weekly Community Meeting agenda
|
||||
- Coordinate with the Bug Czar and ensure bugs are properly triaged
|
||||
- Check whether any bug-fixes must be back-ported to older stable
|
||||
releases
|
||||
|
||||
* ``Every 3 weeks``:
|
||||
|
||||
- Ensure stable branch releases are proposed in case there are any
|
||||
release worthy changes. If there are only documentation or CI/test
|
||||
related fixes, no release for that branch is necessary
|
||||
|
||||
* To request a release of any manila deliverable:
|
||||
|
||||
* ``git checkout {branch-to-release-from}``
|
||||
|
||||
* ``git log --no-merges {last tag}..``
|
||||
|
||||
* Examine commits that will go into the release and use it to decide
|
||||
whether the release is a major, minor, or revision bump according to
|
||||
semver
|
||||
|
||||
* Then, propose the release with version according to semver x.y.z
|
||||
|
||||
* X - backward-incompatible changes
|
||||
|
||||
* Y - features
|
||||
|
||||
* Z - bug fixes
|
||||
|
||||
* Use the ``new-release`` command to generate the release
|
||||
|
||||
* https://releases.openstack.org/reference/using.html#using-new-release-command
|
||||
|
||||
|
||||
Project Team Gathering
|
||||
----------------------
|
||||
|
||||
* Create etherpads for PTG planning, cycle retrospective and PTG discussions
|
||||
and announce the Planning etherpad to the community members via the Manila
|
||||
community meeting as well as the `OpenStack Discuss Mailing List`
|
||||
|
||||
* `Example PTG Planning Etherpad <https://etherpad.opendev.org/p/manila-shanghai-ptg-planning>`_
|
||||
* `Example Retrospective Etherpad <https://etherpad.opendev.org/p/manila-stein-retrospective>`_
|
||||
* `Example PTG Discussions Etherpad <https://etherpad.opendev.org/p/manila-ptg-train>`_
|
||||
|
||||
* If the PTG is a physical event, gather an estimate of attendees and
|
||||
request the OpenDev Foundation staff for appropriate meeting space. Ensure
|
||||
the sessions are remote attendee friendly. Coordinate A/V logistics
|
||||
|
||||
* Set discussion schedule and find an owner to run each proposed discussion at
|
||||
the PTG
|
||||
|
||||
* All sessions must be recorded, nominate note takers for each discussion
|
||||
|
||||
* Sign up for group photo at the PTG (if applicable)
|
||||
|
||||
* After the event, send PTG session summaries and the meeting recording to the
|
||||
`OpenStack Discuss Mailing List`
|
||||
|
||||
Summit
|
||||
------
|
||||
|
||||
* Prepare the project update presentation. Enlist help of others
|
||||
|
||||
* Prepare the on-boarding session materials. Enlist help of others
|
||||
|
||||
|
||||
.. _OpenStack Discuss Mailing List: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
.. _contacting the core team: contributing#contacting-the-core-team
|
||||
|
|
@ -109,19 +109,7 @@ Additional resources
|
|||
For contributors
|
||||
----------------
|
||||
|
||||
Contributions to Manila are welcome. There is a lot of background information that
|
||||
can help you get started. Please feel free to also ask any questions in
|
||||
the **#openstack-manila** IRC channel.
|
||||
|
||||
Getting started
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
* `OpenStack Contributor Guide <https://docs.openstack.org/contributors/>`_
|
||||
|
||||
Contributing to Manila
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Contents:
|
||||
If you are a ``new contributor`` :doc:`start here <contributor/contributing>`.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
Loading…
Reference in New Issue