-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
On 04-10-2010 12:23, Ana Guerrero wrote:
> On Sun, Oct 03, 2010 at 09:52:54AM +0200, Felipe Augusto van de Wiel (faw)
> wrote:
>> On 02-10-2010 23:20, Ana Guerrero wrote:
>>> On Sat, Oct 02, 2010 at 01:07:57AM +0200, Stefano Zacchiroli wrote:
>>>> The Debian project, therefore, invites the Debian Account Managers to:
>>> [...]
>>>> * Establish procedures to evaluate and accept contributors of
>>>> non-packaging work as Debian Developers.
>>>
>>> Reading this, I understand with this GR we would be accepting in advance
>>> whatever procedure DAM consider appropriate to accept contributors of
>>> non-packaging work as Debian Developers.
>>
>> Isn't the case already? I mean, DAM can change that
>> procedure at any time, sure we can have a GR to revert it, but
>> there wouldn't be a difference from what is already in place,
>> they get to decide how people get "full Debian membership".
>
> Exactly, so if DAM can already change that anytime and they have
> already shown they would like to accept non-packaging DD, then
> what is this GR for?
To state it clear as a project? To support them (both
DAM to implement it and non-packaging contributors to became
DDs)?
At least, this is how I feel about this GR and I do feel
sometimes we should do more votes on this way, having a decision
on things that are consensus and that would send a clear message.
Sometimes things are consensus but they are not properly
documented or clearly stated, sometimes it happens with
delegations, the discussion also help to find possible points of
divergence, finding possible flaws, discussing alternative
approaches, improving the proposed solutions that will lead to
new and, hopefully, even better ideas.
> Yes, I know it is to see if the project members agree to have
> non-packagers contributors, then why we need the DAM bit there?
Because once we agree on it what would be the next
plausible step? For me (and seems that it is also for a lot of
other people), the next plausible step is having DAM (and
consequently NM FrontDesk) taking the necessary measures to
accept non-packaging DDs.
Now, one could argue exactly in the other direction, if
we don't put it on the GR because it is obviously, why it is
missing? I believe GRs should have some macro-management aspects
but we can't really put a lot of micro-management on it,
otherwise we will end up with very tied models that we can't
really change (see the -private declassification mess).
After all, it is the wording Zack picked up and a lot of
us agreed on it, I don't think there is any special reason for
having the DAM part on the text, it is just a matter of making it
clear what is the expected outcome of the vote.
And you know, you could have suggested different wording
and got it into the ballot (or even got it changed to your proposed
version as the main proposal).
>>> I have not read all the discussion thread, but it seems there is already
>>> a rough idea of how this will be done. It would be a very good idea and
>>> I would be very grateful if an email, with the general plan of how this
>>> will be implemented, is sent before the voting period begins.
>>
>> IMHO, it may be giving the false impression that this GR
>> is attached with some specific procedure and it is not. The GR
>> is just a matter of state it clear, as a project, that we encourage
>> and accept members that are not code (or packaging) contributors,
>> how they'll be accepted is a different matter, shouldn't be impacted
>> by the rules and I do trust (and expect) DAMs (and NM FrontDesk)
>> will clearly communicate changes on this matter.
>
> I understand this GR as: DAM team, go ahead and establish the procedure
> you think is the best. You assume there will be a discussion, I don't,
> because we are not asking them to discuss, we asking them to implement
> what they think is appropiate. That is why I asked an email from DAM
> about what to expect.
I don't assume there will be discussion because I don't
assume the people entitled to the job have to discuss it, specially
if it is their area of expertise. Call me a dreamer, but I prefer
to believe people will be reasonable, if something affects the
*entire* project, take DMUP as an example, DSA asked input, but in
other situations DSA will just decide what is the best set of flags
to compile the kernel that runs on DSA maintained HW, or the best
cachesize to use with OpenLDAP or the frequency of backups. And
I'm pretty sure they are happen to accept suggestions or comments
on what they are using and that they will try to improve based on
that.
This is the same as any other team I'm aware of, yes, there
are malfunctioning teams, but I think they tend to be the exception
and not the rule. But KDE gets to decide about KDE without having
to discuss on -devel what Apache maintainers think about it, and
vice-versa.
I do assume (and expect) there will be communication on
decisions, be it a privilege change, an access control, or a
procedure to accept new developers (packaging and non-packaging).
And I do fully believe they will accept criticisms and improve
over time, as we are supposedly trying to do in several parts of
Debian in which we are involved in some way. That's also why it
is good to have "Bits messages" from different groups and teams.
> Don't read me wrong, I *want* non-packaging DD, but with the current
> wording, looks like if you want non-packaging DDs, you must accept in
> advance they will be handled according to a unknown procedure. I feel
> some people when faced with this option will vote no.
Let's not fool ourselves and face it. This is *exactly*
what happens _today_. DAM can decide, right now, that new DDs
will be accepted if after sha256sum their names and considering
only the numbers the result is a prime number.
So, don't read me wrong, I also want the non-packaging
DDs, the fact that we know the path for packaging DDs is the
result of several years of NM process, tests, experiences,
errors, suggestions. I'm pretty sure the same will happen,
specially if you consider that we even have templates aimed for
document writers.
Sure, I even think you should address *directly* DAM and
FrontDesk and ask them to carry public discussion on how we
should implement the non-packaging process, but in the end of
the day, the decision is up to them, with or without project
wide discussion.
We can either trust them to be good and reasonable people
that will accept criticism and improve, or we can use the GR way.
> Sure we can override DAM later with a GR, but we clearly do not want that.
I don't think we should be afraid of GRs. If somebody
is doing something obviously wrong, a GR can reach consensus
rather fast, and would even stop the affected item to avoid
greater damage.
> If the text were something like: "inviting DAM to start a discussion in the
> project about the procedures to to evaluate and accept contributors of
> non-packaging work as Debian Developers", it would be different.
Why exactly is that? I don't remember DAM discussing
the actual procedures. I don't believe this is needed in the
GR, as I said, with or without discussion DAM can decide
whatever they want.
And it's pretty clear to me that you can always take
the Debian way, once we get the results of the vote, you can
start a discussion on project to gather people opinion and
invite DAM and FD to join it.
Kind regards,
- --
Felipe Augusto van de Wiel (faw)
Debian. Freedom to code. Code to freedom!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyr8Y4ACgkQCjAO0JDlykZs8QCgxrL51lcyhLDVa7mQaEmarQLO
1XMAoJqL9WCdHhP4LVrgZpNNSDD5dqwj
=4z4D
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cabf190.2080...@funlabs.org
