Those busy bees on the Core 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
  • 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
  • A take on 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

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. 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.

"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.