beeware.github.io/content/contributing/core-team/contents.lr

_model: page
---
title: Core Team, and Responsibilities
---
sort_key: 3
---
summary: What is the core team, and what do they do?
---
body:

Those busy bees on the `Core Team </community/team>`_ have a number of
responsibilities to keep the hive that is BeeWare moving. This is an evolving
project, so this page is subject to change.

These include, but aren't limited to, responding to issues, reviewing and
merging code, mentoring new contributors, and architecture of the BeeWare
project as a whole.


There are people we trust to make code decisions; there are people we trust to
make code and organizational decisions; and there is a person who guides the
vision of the whole organization, and is entrusted to make a final decision
if the community cannot arrive at a consensus.

These levels can be described as follows:

Bee, or Worker Bee:
 - Any member of the BeeWare community. Given we work in the open on GitHub,
   anyone can suggest changes to the code and have their code merged. The only
   limit to your ability to contribute is having your work merged by a team member
   with the rights to do so.

Apiarist:
 - A bee who has been recognised as a trusted contributor. These bees have
   demonstrated ability in relation to a specific part of the BeeWare project over
   a period of time. This could be on a technical level (JavaScript, Python,
   Objective-C expertise; GTK+, macOS knowledge), or on another level (community
   management, code review). Apiarists may also have the commit bit for the project
   where their expertise is recognized.

Senior Apiarists:
 - Apiarists with elevated access in GitHub, and also an added level of
   responsibility to oversee the project as a whole. They are able to make
   architectural decisions, but ultimately answer to the BDFN.

Founding Apiarist: `Russell Keith-Magee <https://mastodon.social/@freakboy3742@cloudisland.nz>`_
 - The man that first stood on a hill and spied a yak that needed shaving
 - This role never changes, and continues ad infinitum
 - This role is different to the BDFN role

Bee-nevolent Dictator for Now (BDFN): `Russell Keith-Magee <https://mastodon.social/@freakboy3742@cloudisland.nz>`_
 - A take on `Benevolent Dictator for Life
   <https://en.wikipedia.org/wiki/Benevolent_dictator_for_life>`_,
   responsibility for the direction and decisions of the project ultimately
   lies with the BFDN. The use of "For Now" as opposed to "For Life" is
   reference to the Django theme of not subjecting the responsibilities
   of core maintainer for a person's entire natural life. Life exists
   outside open source, and code/life balance and general well-being
   is a very important thing to keep in mind.


Guidelines (not actual rules)
------------------------------

As with any project with more than one person with commit rights, there are a
number of general guidelines that the team should follow:


 * **Be a good representation of the project to the wider community**

 * **Treat every enquiry and contribution to any BeeWare project with respect.**

 * **Assume everyone has good intentions, even if they haven't chosen their
   words well**

 * **Assume that if someone has done something the "wrong" way, it's because
   we've failed in communicating process**

 * **Assume any expression of anger or frustration comes from a genuine place of
   wanting to use a BeeWare tool/library**

 * **Encourage other members of the community to reflect these ideals in their
   own communications, both inside and outside the BeeWare community**

 * No Apiarist should commit their own code
     - Exception: "Something is very broken and needs to be fixed now"
     - Exception: BDFN (this may change in the future)

 * All code submitted for review by a core team member should be reviewed by another team member
     - Exception: BDFN (this may change in the future)

 * All code should pass Continuous Integration tests before being merged
    - Exception: code that is known to be broken and needs to be committed for other reasons
    - Exception: code in a repo with insufficient CI tests
    - Exception:  Working and committed is better than perfect and not

 * Acceptance processes should be automated wherever possible
    - This means tests, linting, spell checking, coverage, and more.
    - This is now a `proof of concept </project/projects/tools/beekeeper/>`_




Becoming an Apiarist
---------------------

Introduction of a new Apiarist into the team is at the sole discretion of the
existing Core Team. While there are not currently any solid rules to this, in
general, someone will be invited to be an Apiarist on a BeeWare project if they
have demonstrated solid contributions to the project. This can also be extended
to someone with specific domain knowledge (for example, iOS/macOS) which might
be lacking in the existing team. It also doesn't have to be based on commits.
Anyone who is able to demonstrate a vested interest in the project in general
may ask to be given permission to commit to the project.

All new apiarists will be 'inducted' (for lack of a better word) in the core
values and guidelines of the project. A summary of the core values can be found
`on the about page </project/about/>`_. Anyone who joins the
team will be expected to uphold those values, and contribute to discussions
about evolving those values over time.

Any Apiarist, new or old, isn't expected to be the sole maintainer of any one
thing. There are many apiarists, and many more beside who can offer help, advice
and mentorship.

---
gutter:

"Commit bit"?
--------------

In Unix systems, a single bit in a file is used to denote permission to execute
a file. In source control systems, a similar bit exists to denote the ability to
merge code. To say someone has the "commit bit" means they have write-access to
a code base. In GitHub terms, this means they have the ability to merge Pull
Requests and commit code directly to the project.