| Author: | Thomas Anderson (irc: tanderson, ballot: gentoofan23) |
|---|---|
| Contact: | gentoofan23@gentoo.org |
| Date: | 04 Jun 2009 |
I first would like to thank the general developer community for the overall positive experience I've had over the past three years working with Gentoo. I'd also like to thank the outgoing council for the mentorship and trust they've given me, I've learned quite a bit from them.
I've been involved with the Gentoo community for 3 years now. I was an active Arch Tester for the AMD64 project for two years, and an official Gentoo Developer for a year. As a developer I've been involved with the sunrise project and AMD64. I've also been the secretary to the Gentoo Council for the past six months. As the secretary, I've become intimately familiar with what the Council does and have garnered experience that enables me to judge what Gentoo needs in the coming year. My occupation is a student which I will be for the next 6 years or more so I'll have plenty of time to devote to the Council.
Please Note: My name on the ballot is 'tanderson' but I have previous known as 'gentoofan23' and have done much of my work in the past years under that nickname.
This past year, we've had quite a few contrary opinions on various things. What's compounded the problem of lack of agreement is the lack of positive work towards an end goal -- instead of working together for a commone desire and goal we try to show why other people are wrong. What I intend to do is to have positive discussions towards a goal (How can we change, improve, and refine proposals to have greater acceptance ). I've been doing this some in the past and I believe it is the correct way to move forward.
Apart from what is mentioned above, my major goals (I have smaller goals that likely aren't relevant to a platform) are as follows (in no particular importance):
We must handle this transition smoothly. We'll need to make sure all documentation is updated. We may need to appoint people (or do the work ourselves) for this. We need to actually make use of git's strongest asset to the Gentoo community -- external contributors. With git, there's nothing special about being a developer except that you have push access. With git, anyone can make a commit, but few can push. If we can broadcast to our userbase that being a 'dev' is nothing fancy and that anyone can make commits which are simply signed off on and pushed we will have greater enthusiasm in the community and benefit us by more than patches we don't need to use repoman on. In my opinion, this can strengthen us and bring the rift between the user community and developer community much smaller.
I intend to institute a "friend of the council" system where interested individuals (not necessarily developers) can privately email the council with their opinions and insight into the problem at hand. The advantage of this is that council members do not have to wade through 200 -dev emails that have hostile disputes between multiple factions to determine the technical arguments in favor and against the proposal at hand. I think this will make it simpler for council members to know the pros/cons of each. Note that this doesn't mean that I think that if people in favor of a proposal send in more emails than those against a proposal I will vote in favor of the proposal, far from it. Nor would this mean council members do not need to read -dev, dutiful reading of -dev is a council member's responsibility.
Six month discussions with no results are unnacceptable and we need operate on a goal-oriented basis where we know a problem(first we must agree there's a problem), possibly a proposed solution and then have various 'blockers' that need to be solved before accepting the solution and having the problem eliminated. Part of the council working smoothly is to present our opinions and discuss blockers on-list before meeting and then voting and any last-minute (there should be few of these at the meeting however) discussions at the meeting in a +m(moderated) environment, voicing individuals as desired for input. This'll avoid the back and forth in meetings that really should happen on list before meeting.
Since development occurs at a fairly quick pace, the developer manual that all new ebuild writers consult becomes out of date. To ensure that all information that new contributors encounter is up to date we must strive to keep devmanual up to date which will avoid those situations where general knowledge among devs conflicts with our documentation. In my opinion the developer manual should be considered part of our critical infrastructure, without it ebuild quality goes down and time is wasted repeatedly explaining things that should be in our general documentation. If elected, I will work with devrel to merge the old, outdated ebuild handbook into devmanual, extracting the parts that are still relevant and not in devmanual.