[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: metaphors and feminism



Sam Hartman writes ("Re: metaphors and feminism"):
> I always assumed debian member was a term that included developer and
> maintainer.
> I'm all for Debian member replacing developer, but if so, I'd like a
> term that encompasses maintainer and developer.

There are at least the following statuses/roles:

 1. "Debian Developer" as per the constitution.
 2. "DM" aka "Debian Maintainer", ie someone in the DM keyring
 3. "Maintainer:" or "Uploader:" in some source package
 4. Other contributors

You can vote in GRs and DPL elections if you are 1.
You become 1 by going through the NM process, which is supposed to
guage your technical and nontechnical suitability.

You can upload a particular package without needing sponsorship if you
are 1; or are 2, and also 3 for the package in question.
You usually become 2 by demonstrating a track record of good
contributions in role 3.

You may make management decisions[*] with respect to a particular
package if you are 3; you are also then primarily responsible for
preparing new versions, although you need a sponsor to upload them
unless you are 1 or 2 as well.


Your comment was ambiguous as to what you meant by `maintainer': did
you mean 2 or 3 ?

I think Paul has been using `member' to mean only 1.  I think that is
appropriate: `member' is then highest status that is not membership of
some special group.

3 is usually called `maintainer'.  `Maintainer' is actually right for
this role: it refers to the responsibility and authority for package.
So we need a different term for 2.

Lots of organisations use `associate'.  And 2 are specially
authorised.  Hence my suggestions of
  Authorised/Approved Debian Maintainer
  Associate Debian Member

I think the former is better because the status 2 implies only a
technical authority, not a sociopolitical authority.


Thanks,
Ian.


[*] By `management decisions' I mean, for example: giving go-ahead for
an NMU; approving/disapproving proposed patches; deciding what VCS and
packaging workflow should be used; helping choose other members of the
package team; filing a removal request; deciding on a bug severity;
negotiating with those handling other packages.  If there are others
listed as Maintainer/Uploader then these decisions are collective.
And most are subject to possible review by eg release or ftp team,
etc.  But, this is the most usual kind of authority in Debian and it
is not gatekept by any kind of access control mechanism; rather like
any management decision, it is a kind of authority honoured by humans
rather than computers.


-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: