Bug Triage ((TBD))

Kubuntu Council

The Kubuntu Council has six members. Membership lasts for two years. The three longest service members change each year. Elections for the vacant positions are being held around May.

Council meetings have a quorum with a simple majority of members (four) present.

Election Process ((TBD))

[insert rubbish about timing and link to council mail templates]

Kubuntu Teams - ((NEW))

The purpose of this policy is to clearly outline the requirements one has to fullfil to become a member of any of the Kubuntu Launchpad teams.

~kubuntu-council

The only way to join the council team is being elected which will result in one of the present members adding you to the team. All members are also administrators of the team.

• Requirements: Getting elected.

~kubuntu-dev ((TBD))

[...]

~kubuntu-members

Kubuntu Members are the most trusted and devoted members of the community, having gained public recogination for their work on Kubuntu by being accepted as official Kubuntu Members.

• Requirements: More than six months acitivty, love for Kubuntu, survive an interview by ~kubuntu-council and existing ~kubuntu-members. ~kubuntu-council holds formal vote on whether to accept an applicant.

• Notes: Members, while not having any upload or bug control permissions, are meant to be trustworthy and act in the best interest of the project. ~kubuntu-members consequently also are members of all other Kubuntu teams that do not have additional requirements other than trust.

• ((TBD: how to apply))

~kubuntu-ninjas

Kubuntu Ninjas are the elite KDE software update packagers.

• Requirements: Trusted enough to not break PPAs and produce good enough quality for ~kubuntu-dev to approve for an archive upload.

• Notes: Ninjas can not directly push changes to ~kubuntu-packagers owned branches because those are the heart of our packaging and must only be changed by someone trusted enough to not have malicous intent.

Psuedo Teams

The following teams only allow pseudo membership and are used for organizatinal purposes. Thse teams should not be joined directly, but instead the team mentioned in brackets. When in doubt, check the members of a team. If ~kubuntu-members, ~kubuntu-ninjas or ~kubuntu-dev is a member, then the team likely is a pseudo team and should not be joined directly.

• ~kubuntu-active [~kubuntu-members]
• ~kubuntu-kdesudo [~kubuntu-members]
• ~kubuntu-netbook [~kubuntu-ninjas] (note: should be changed to -members, however the team is pretty much deprecated)
• ~kubuntu-packagers [~kubuntu-members] (note: various ubuntu teams are also member)
• ~kubuntu-ppa [~kubuntu-ninjas | ~kubuntu-dev]

Free-For-All Teams

These teams can be joined by anyone who wishes to take part in their mission.

• ~kubuntu-bugs
• ~kubuntu-users

Patching ((TBD))

"Patches are evil." - apachelogger around 2009

If you think this policy sounds a lot like a PITA then you are absolutely right and the policy works as intended.

Whenever upstream does not approve of a patch, it must not be included or must be removed. There is no exception to this rule.

Upstream vs. Downsteram ((TBD))

Merging

When merging with Debian's packaging, each patch must be reviewed with regards to upstreamability to KDE or Debian. If a patch qualifies, upstreaming it should be proposed to the affected upstream; TODO tasks to track progress on upstreaming should be created whenever necessary.

Documentation ((TBD))

Patch Naming

Patch names ought to denote their origin and purpose as precise as possible.

The general naming scheme is: <origin>_<description>.[patch|diff]. If a patch is obtained from a VCS or another distribution the original description should be preserved in order to enable third parties to trace the patch.

Examples:

• kubuntu_magic-unicorn.patch (own patch)
• upstream_fix-air-ejection.patch (upstream git commit)
• fedora_add_rainbow.patch (patch imported from fedora without changes)
• bko_remove-spaceship.patch (patch from a bugs.kde.org report)

Policy Approval

All policies must be approved by the Kubuntu Council.

Stable Updates ((TBD))

Support (as in Long Term Support) ((TBD))

Global Fallback

Whenever we have no policy for a specific matter listed here, the relevant upstream policy ought to be applied whenever possible. In particular all code ought to follow upstream policies with regards to style, licensing and documentation.