1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
============================
So You Want to Contribute...
============================
For general information on contributing to OpenStack, please 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 Kolla Ansible.
Basics
~~~~~~
The source repository for this project can be found at:
https://opendev.org/openstack/kolla-ansible
.. _aicontent:
AI-Generated Content
~~~~~~~~~~~~~~~~~~~~
In general, please do not submit AI generated content to the Kolla
project, but some exceptions apply.
The OpenInfra foundation has created a policy for AI Generated content
at https://openinfra.org/legal/ai-policy which provides useful
background to the Kolla project's policy, but the Kolla project policy
differs somewhat.
As a free software project, we are concerned with the copyright
ownership of the project's source code. Because most commercially
available LLMs are not able to indicate whether their output may
include training data incompatible with Kolla's licences, accepting
substantial contributions generated by them increases the risk to the
project. And because LLM-generated output is not considered
copyrightable in the United States and other regions, that further
increases the risk to the project.
In many cases, the code and documentation output from LLMs is not of
sufficient quality for easy incorporation into Kolla. A community of
contributors and reviewers with deep understanding of the project is
healthier in the long run. Contributions generated by LLMs without
that understanding creates more work for the maintainers.
Nevertheless, if you use an LLM to create a very small patch (one that
would likely not be subject to copyright protection even if generated
by a human), that's fine, but you must annotate it with the
`Assisted-By` or `Generated-By` labels.
In short:
* Please do not submit substantial AI-generated content (code or docs)
* Very small/limited use may be okay if it's not copyrightable
* Make sure you fully understand the code or docs you are changing
* If you don't, engage with humans in the Kolla community
* Any AI-Generated content must have `Assisted-By` or `Generated-By` labels
.. _communication:
Communication
~~~~~~~~~~~~~
Kolla Ansible shares communication channels with Kolla.
IRC Channel
``#openstack-kolla`` (`channel logs`_) on `OFTC <http://oftc.net>`_
Weekly Meetings
On Wednesdays in the IRC channel (`meeting information`_)
Mailing list (prefix subjects with ``[kolla]``)
http://lists.openstack.org/pipermail/openstack-discuss/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/Kolla
Whiteboard (etherpad)
Keeping track of CI gate status, release status, stable backports,
planning and feature development status.
https://etherpad.openstack.org/p/KollaWhiteBoard
.. _channel logs: http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/
.. _meeting information: https://meetings.opendev.org/#Kolla_Team_Meeting
Contacting the Core Team
~~~~~~~~~~~~~~~~~~~~~~~~
In general it is suggested to use the above mentioned public communication
channels, but if you find that you need to contact someone from the Core team
directly, you can find the lists in Gerrit:
- kolla-core https://review.opendev.org/admin/groups/28d5dccfccc125b3963f76ab67e256501565d52b,members
- kayobe-core https://review.opendev.org/admin/groups/361e28280e3a06be2997a5aa47a8a11d3a8fb9b9,members
New Feature Planning
~~~~~~~~~~~~~~~~~~~~
New features are discussed via IRC or on the openstack-discuss mailing list
(please include the [kolla] prefix to your subject line).
Kolla has previously used Launchpad blueprints, but now simply uses tracking
bugs for new feature work. Please tag any such bugs with a "[RFE]" prefix,
which indicates the bug is a Request For Enhancement. Bugs are discussed in
more detail in the next section.
Task Tracking
~~~~~~~~~~~~~
Kolla project tracks tasks in `Launchpad <https://bugs.launchpad.net/kolla-ansible>`__.
Note this is the same place as for bugs.
If you're looking for some smaller, easier work item to pick up and get started
on, search for the 'low-hanging-fruit' tag.
A more lightweight task tracking is done via etherpad - `Whiteboard <https://etherpad.openstack.org/p/KollaWhiteBoard>`__.
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/kolla-ansible>`__.
Note this is the same place as for tasks.
Getting Your Patch Merged
~~~~~~~~~~~~~~~~~~~~~~~~~
Most changes proposed to Kolla Ansible require two +2 votes from core reviewers
before +W. A release note is required on most changes as well. Release notes
policy is described in :ref:`its own section <release-notes>`.
Significant changes should have documentation and testing provided with them.
Project Team Lead Duties
~~~~~~~~~~~~~~~~~~~~~~~~
All common PTL duties are enumerated in the `PTL guide <https://docs.openstack.org/project-team-guide/ptl.html>`_.
Kolla Ansible-specific PTL duties are listed in `Kolla Ansible PTL guide <https://docs.openstack.org/kolla-ansible/latest/contributor/ptl-guide.html>`_.
|
