From: William Hubbs <williamh@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: [gentoo-project] williamh 2021-2022 council manifesto
Date: Mon, 28 Jun 2021 23:19:45 -0500 [thread overview]
Message-ID: <YNqfYWDkRjYoO1I2@linux1.home> (raw)
[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]
Hi all,
In case you are wondering why I didn't send this sooner, I was on a
vacation for the last week.
for those of you who don't know me, I have been a Gentoo developer and a
maintainer of OpenRC, member of base-system, the accessibility project,
and a maintainer of multiple packages in the tree for some time.
I also have served on the qa team in the past.
I have served on the council for several terms, and I would like to have
the priviledge of serving for another term. Below are my thoughts about
the council and what I think we can do.
The council should be asked to make a decision on an issue only when
the issue cannot be settled by the community itself. Innovations should
come from the developers, and the council should do what it can to
support these innovations.
When the council is asked to make a decision, it should be fully
informed about both sides of the issue before it votes. On the other
hand, the council should not block progress by taking an extremely long
time to make a decision.
We can learn from the past and improve upon it. Continuing
to do things like we have in the past is not a bad thing in itself.
However, using what we have done in the past to block change can be. I
understand that people are used to doing things a certain way. However,
that alone is not justification for continuing to do things the same way
in the future. if we need to make a change, we should make sure that
change is backward compatible with what we have, or if this is not
possible, provide the smoothest possible transition for our users.
Since the council doesn't maintain all of the packages, the council is
not going to know the technical details of how to make either of these
happen, so I don't feel that the council should mandate specific
implementations.
If anyone has any questions for me, please feel free to ask in this
thread. Also, I will be responding to the questions for nominees thread
tomorrow.
Thanks for your time, and please participate in the election.
William
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
reply other threads:[~2021-06-29 4:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNqfYWDkRjYoO1I2@linux1.home \
--to=williamh@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox