-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We're happy to see feedback on the list in regards to our recent
message about electing project leads. Hopefully there's been enough
time for everyone to get their few cents in. At this point, we'd like
to clarify what would change were we elected as leads, as well as
iron out the details of the election process.
Operations:
1) Development of General Team Policy - With only four active
developers, it has been pretty easy to develop consensus on how we as
a project treat different situations. Our recent agreement to switch
to 'use userland_Darwin' instead of 'use ppc-macos' in ebuilds is an
example of this. However, the project will not always consist of four
people (it now effectively consists of six active members). Since we
are a relatively new project, we can avoid some of the issues that
plague the -core and -dev mailing lists by keeping a general policy
page up to date from early on (I.E. now). This will also be of great
help to new developers and potential contributors. It might not be
critical now, but as we expand as a project into the future, it will
become more and more important.
2) Intraproject Relations - Some of us are self-motivated and like to
do our own thing while others want direction. I am hoping that part
of our problem with inactive developers comes from this lack of
direction. Furthermore, if we all do our own thing without any
central coordination, we will inevitably end up duplicating work
(this has already happened more than just once). For both of these
reasons, we think it might be a good idea to keep a listing of what
each developer is working on with regards to the project (perhaps on
the project page, which we all have CVS commit access to). For
instance, Lina maintains a package in sci-biology and she maintains
the sci-biology category for ppc-macos. We're not looking for a list
of packages people are involved in porting each week; we're looking
to keep track of long-term goals that each developer is working
towards. This is also good for PR purposes, as well as in the
recruitment/contributions department. (We don't feel that Bugzilla
isn't suited for keeping track of each developer's current work in
this way.)
Strategic:
1) Recruitment - Let's face it, we need more devs, badly. To make the
recruitment process more manageable and coherent for all parties
involved, some sort of central recruitment liason(s) need to be
available and announced as such to the outside world. While virtually
any developer is able to recruit, it's not as easy as just announcing
open positions or a need for help, and then watching the e-mails come
in. We tried that, and it didn't work so well. Often the best
applicants are those who don't apply themselves. Fabian, our most
awesomest recent recruit, did not send us an e-mail; rather, we e-
mailed him after seeing some of his activity in Bugzilla. It's a
pretty safe bet to say that good recruitment involves a decent amount
of administrative work and research. Recruitment isn't just about
getting new blood into the team either, though; there's a long
training process involved (both before and after application for
developer membership), and for this to be effective, a central
training body needs to be established for the outside world to be
able to correspond with. We don't want to repeat the initial
recruitment disaster -- it's not fair to the rest of the Gentoo
community, and it's not fair to the new developer not to receive
adequate attention and training. As such, we plan to keep the
recruitment process slow and sure.
2) Public Relations - This is something we're not even near having
enough of. The documentation is outdated, and profile changes often
go unannounced until after the fact, if they're announced at all.
We're really happy to see some traffic on this mailing list again,
and this needs to continue to improve. In case not everyone noticed
yet, we, along with a few other devs, have been trying to promote ML
traffic as of late, as opposed to getting things done via IRC and
keeping them unannounced otherwise. We feel that this is a great PR
move, and more action like this in the future needs to be built upon.
Specifically, changes to the profile and anything that would qualify
subjectively as large progress should be announced to the mailing
list -- it's important to keep users informed of changes, and
progress is great for keeping interest in the project. For example,
if a use flag is removed from use.mask, it should be publically
announced, as should news on major packages, such as baselayout-
darwin or perl. Having a lead responsible for this keeps things
easier on everybody. Of course, any other developer that wants to
announce their own progress notes is more than welcome to do so. ;-)
3) Interproject Relations - In addition to PR, we need a designated
liason to the rest of the Gentoo community. This becomes particularly
important when other Gentoo projects need to interface with the Mac
OS X project, and vice versa. For example, if a developer from
another project has a Mac and wants to keyword their own packages,
they need to be aware of project policies (such as the use of
userland_Darwin). Having a designated person to go to for this sort
of thing is easier than the current free-for-all situation. After
all, this developer is helping us out; the least we can do is make
things easy for him/her. On the flip side, there needs to be a
designated person to deal with interproject conflicts. While this
isn't exactly a fun job, it's better to have one unified face than to
have split personality disorder. We are a project, not just a group
of developers that occasionally talk to each other.
4) BugDay Participation (Operations && Strategic) - BugDay is a great
way to meet new potential developers and to allow current developers
to take time off from their current blocker-problem and tackle some
easier stuff. We haven't been utilizing the potential here as much as
we should be. We have a lot of bugs in bugzilla and we all know that
it can be a bit overwhelming sometimes. We might make better
progress if all of us agreed on a short list of things we wanted to
tackle in a day and took some time once a month to work together on
them. Pine and Pango come to mind as two recurring problems we might
be able to solve in such a session. The purpose here isn't to solve
large problems, but to solve wide-spread 'little' problems. It has
the additional benefit of introducing current developers to fresh
blood, and vice versa.
To summarize, we are not looking to dictate development or assign
duties to developers. We recognize a need for someone to assume some
of the administrative roles, and we are offering to fill them. This
project has made a great deal of progress by allowing its developers
free reign to pursue their individual interests. No point in fixing
this; it isn't broken.
If there are any questions about any of the above, please voice them!
We are always open to suggestions.
In regards to actually voting, what does everybody feel on this?
Should there be a formalized election (such as the use of 'votify'),
or should there just be a public vote on IRC or via e-mail? Since
this hasn't been done before within the Gentoo for Mac OS X project,
we're breaking new ground here. Please make your opinions known!
Also, how much time should be allowed for other developers within the
project to announce candidacy?
- --
Hasan Khalil && Lina Pezzella
Ebuild & Porting Co-Leads
Gentoo for OS X
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFC+tNSNJ9STR9DbYERAtjQAJ0YctzJGppbD54+5CNPxuuChNUKaQCfaJUS
xatTyO7tr1UlPXsOsxjf/BA=
=a8im
-----END PGP SIGNATURE-----
--
[email protected] mailing list
