Manifesto for 2013/2014 council elections

About me:
My name is Chí-Thanh Christopher Nguyễn (chithanh). On IRC people know me by my
nick "chithead". I am mainly active in the x11 and radio teams, and
occasionally in voip and sunrise.

My bid for the council:
Gentoo - A distribution for grown-ups

Recently, a lot of noise was made from developers regarding the inclusion of
non-upstreamed systemd units into packages, which has shifted to a discussion
about developer conduct and policy. My position on these topics is as follows:

1. A maintainer has say over his packages. If you want to make a change to his
package, you have to convince him to approve this change. If your arguments
fail to convince him, then you don't get to run crying to the council demanding
that they overrule the maintainer. Only when the package violates policy, or
this change is necessary to preserve choice or a working system for users, then
you can expect others to step in.
But if there alternative possibilities, such as maintaining your changes in a
separate package, then you have to accept the maintainer's decision.

2. Nobody should have to endure personal attacks or insults on Gentoo. I
support that devrel and the Council respond to complaints about insults and
issue a warning or suspension against offenders. However, I do not support that
mailing lists, forums and bugzilla are being policed in search of infractions.
In addition, derogatory remarks against ideas, concepts, proposals or pieces of
software may be a sign of immaturity, but not an offense that is worthy of
punishment. Same goes for unsound arguments of any kind (ad hominem, false
dilemma, strawman, etc.).

I do think that Gentoo can function as a collection of individuals, if we
respect each other and we accept that someone else may not care about the same
things that we care about. Encouraging developers to cooperate and act
reasonably is a good thing. Forcing decisions on them should be avoided where
possible.

********************************************************************************

Q&A Section added on 2013-07-01:
Most of these questions were posted by hasufell and rich0 on gentoo-project. I
thank them for bringing up these questions, so the readers of this Manifesto can
have a better overview of my positions.

Q: Do you think package forks or split-packages for single files would improve
user experience?
A: Package forks will decrease usability to some degree. As long as proper
documentation exists and the number of forked packages remains manageable,
there is no serious problem however. After all, users who run Gentoo have to
make informed decisions all the time already.

Q: What should be our priority? Keeping devs happy or keeping users happy?
A: The priorities and discrimination between users to care about, and users to
not care about, are set by each individual developer. Some priorities are shared
between almost all developers, for example we do not care about users who refuse
to read documentation and expect a one-click install. In other areas, there is
less consensus, especially when it comes to controversal topics.

Q: I want to apply a change to an ebuild, but the maintainer refuses. Can I
force him to accept my changes?
A: If your change is required by Gentoo policy, then the maintainer must accept
this change. If necessary, take it to QA or the council. However, if your change
is not required for policy compliance, then you must convince the maintainer
first.

Q: My arguments did not convince the maintainer, but I really want to apply this
change. I think the maintainer rejected it unreasonably. What can I do?
A: If direct talks between developers are unsuccessful, the council can offer to
mediate or appoint someone who does. We will try to reason with the developers
to arrive at a solution that all sides can accept. Mediation will however not
result in forcing the changes onto the maintainer.
If mediation fails, then you still have the option to fork the ebuild and
maintain your changes there (GLEP 39).

Q: But can maintainers then just drop stable ebuilds at will, do bad things to
users' systems etc. while nobody can do anything about it?
A: No, policy dictates that ebuild removal must follow proper procedure. Changes
which will break users' systems are not allowed either and will be reverted.

Q: If a maintainer does not want to accept any outside contributions to his
ebuild, shouldn't he just maintain it in an overlay instead?
A: The maintainer rejected your change, this does not mean that he rejects all
contributions. We should encourage developers to maintain their ebuilds in
portage and not in overlays, as long as they work and conform to policy. If you
think that the maintainer does a bad job, offer to co-maintain the package. If
that is rejected, fork the ebuild and show that you can do better.

Q: Let's assume the apache ebuild is forked. Do you want the version of apache
that contains backported bugfixes but vanilla config files, or the one that has
gentooified configs but no init-script?
A: I consider this scenario unlikely, because I expect that any package fork
will be done with the intention of swaying as many users as possible to the new
package. Therefore, it will probably include most if not all functions of the
original package.

Q: Do you think that Gentoo should become some kind of free-for-all where
every developer only cares about his turf and disregards all others? Isn't that
going to end in chaos?
A: I strongly believe that Gentoo community can work together and reach the goal
of making a powerful distribution that is giving users choice and the tools that
they need to form their system according to their needs. And I think that the
best way to achieve cooperation is to convince the involved persons about the
benefits of cooperation. And it won't be real convincing if the maintainer sees
the threat that he will be forced to cooperate anyway. Any kind of forcing
should be kept to the neccessary minimum; at current this is mostly QA and legal
rules.