Re: [gentoo-osx] Elections for Project Lead Positions

[Finn Thain]

On Thu, 11 Aug 2005, Lina Pezzella wrote:

> -----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.

Good idea. Question is, will all developers commit to keeping it current.

> 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.)

CVS may not be a good way to improve communication, it might need to be 
more convenient before people will use it.

> 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.
>    ;-)

Absolutely. Unlike IRC, mailing lists represent searchable archives of 
useful information and solutions to common problems.

However, this is not PR, just good communication. Good PR just isn't 
sufficient in the open development model. This is something even apple is 
still trying figure out.

> 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.

Having a dedicated role for this is misguided. IMHO, every gentoo-osx 
developer should be continually involved with other parts of the wider 
Gentoo developer community, simply in the course of their job. Also, every 
gentoo-osx developer should be responsive to other members of the wider 
Gentoo developer community, just to share the load.

To create such a dedicated role is to encourage the other devs to believe 
they can work in isolation. It also bottlenecks access to the project 
team, which is only really useful if you are trying to contrive some sort 
of public image.

If this proposal is a reaction to one dev shooting his/her mouth off and 
those views being mistaken as representative of the entire project, then 
there are better solutions.

>
> 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.

Isn't there an initiative to allow users and developers to vote on bugs?

> 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.

I think yours is a great post because, while I may not completely agree 
with every point, this stuff should be discussed.

-f

> 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-----
>
-- 
gentoo-osx@g.o mailing list