Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Raphael Hertzog]

On Tue, 30 Dec 2008, Joerg Jaspert wrote:
> Hi,
> 
> I have felt for some time that the low requirement for seconds on General
> Resolutions is something that should be fixed. We are over 1000
> Developers, if you can't find more than 5 people supporting your idea,
> its most probably not worth it taking time of everyone. Various IRC

Why are you saying 5 ? Your proposal requires 30.

Recent votes have shown that some options tended to have more
seconds than the others but we never reached 30. We had 17 for
"Exclude source requirements for firmware" and 21 for 
"Invite the DAM to further discuss until vote or consensus, leading to a
new proposal.".

Note that with those new requirements some interesting
amendments/alternate choices would not have made it in several of the votes
(although different rules would have probably lead more people to second).

Anyway 2Q is too much in my opinion. Q would be much more reasonable.

It would be also be good to add a sentence inviting the seconders to
explain why they second the proposal. At least it would make the many
formal mails to second proposals somewhat interesting to read
(they could even be linked from the vote web page so that voters who have
not taken part in the discussion can refer to the reasoning of those who
have brought the option to the vote).

> only. I'm *not* calling for seconders with this mail. Thats also the
> reason for the reply-to/mail-followup-to header going to -project,
> please respect them.

List-reply ended on both lists, I had to hand-edit the result.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Ben Finney]

Russ Allbery  writes:

> Sure, I'm all for clarity and precision. I just don't see a reason
> to put the ones that no one wants to champion on the final ballot.

Nor do I. You still seem to be making an unnecessary connection
between “the option isn't well supported enough to be on the ballot”
and “there's no good reason to propose the option in the first place”.
That, or you seem to think I'm proposing to lower the barrier of entry
for options, once proposed, to appear on the ballot; that's not what
I'm saying either.

I think it can be a good idea to propose an option that one wants to
see voted on, especially if one honestly thinks that option could
represent the opinion of other people in the vote.

I do tend to agree that *seconding* an already-proposed option that
one doesn't intend to rank high is less justifiable than proposing
such an option.

-- 
 \   “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Ben Finney]

Don Armstrong  writes:

> On Tue, 30 Dec 2008, Ben Finney wrote:
> > Another purpose, that I've seen recently a few times, is people
> > proposing *several* discrete options for a ballot, carefully
> > phrasing them to be distinct in order to clarify the meaning of
> > the vote's result.
> 
> If no one is going to rank those options highly, there's no purpose
> in proposing them.

Agreed on that.

> I could see someone drafting them as an option for someone else who
> planned on ranking them highly to actually propose and second.

Fine. Your original statement denied this possibility, which was all I
wanted to address.

> > According to Don's statement above, this is not a good reason to
> > propose options. I disagree; I think it's commendable and in the
> > spirit of his earlier statement (in the same message) to strive
> > for clarity and precision in the ballot options.
> 
> Options that (almost) no one actually supports don't increase
> clarity.

It's this implicit binding of “the proposer doesn't support the
option” with “(almost) no-one actually supports the option” that I
find unneccessary and overly restrictive. It seems you agree, but your
terminology suggests otherwise.

-- 
 \ “This world in arms is not spending money alone. It is spending |
  `\  the sweat of its laborers, the genius of its scientists, the |
_o__)   hopes of its children.” —Dwight Eisenhower, 1953-04-16 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Russ Allbery]

Ben Finney  writes:

> I get the feeling you've excluded the middle between “propose an option
> one does not plan on raking first”, and “propose an option no-one
> wants on the ballot”.

I'm not sure that I find it usefully different, unless what you're
proposing is a compromise that you hope everyone will be able to agree
upon.  I suppose that's a useful addition to Don's statement; I could see
proposing that even though it wasn't one's first choice.

> Another purpose, that I've seen recently a few times, is people
> proposing *several* discrete options for a ballot, carefully phrasing
> them to be distinct in order to clarify the meaning of the vote's
> result.

I think that's a good exercise to write clear proposals, but I don't see a
reason to then formally propose all of them.  I'd write them all up as
part of that exercise and then propose the one that I agree with, offering
the others to those who agree with them to put forward if they choose.

Writing options that you don't personally agree with is full of problems.
It's very difficult to be objectively fair in capturing an option that you
don't believe in and wouldn't argue for.  I'd much rather see the people
who really believe in an option step forward to propose it.

> According to Don's statement above, this is not a good reason to
> propose options. I disagree; I think it's commendable and in the
> spirit of his earlier statement (in the same message) to strive for
> clarity and precision in the ballot options.

Sure, I'm all for clarity and precision.  I just don't see a reason to put
the ones that no one wants to champion on the final ballot.

With Condorcet voting and Further Discussion, there seems to be little
point in trying to flesh out a ballot with all possible distinct options
just out of some sense of completeness.  If one of those options that no
one seconded turns out to be what the rest of the project who wasn't
participating in the proposal process wanted, that's what Further
Discussion is for (and I expect that to be quite rare).

As far as I'm concerned, the ideal outcome of a GR discussion isn't a
ballot with all options represented.  It's a project-wide consensus on the
best course of action.  When that happens, there's no need to have
anything other than the consensus on the ballot, and if something went
wrong with that process, there's always FD.  I want to be working towards
agreement, not towards getting everyone's starting position on the ballot.
I think the current low threshold for amendments and the habit of
proposing or seconding ones one doesn't agree with is counter to that;
once something is seconded and on the ballot, I think it takes a lot of
steam out of the discussion and reduces the chances of a general consensus
compromise.

Which is one of the reasons why I think Jeorg's proposal is a good one (to
bring this back to the original thread topic).  I agree that the threshold
feels too low currently.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Don Armstrong]

On Tue, 30 Dec 2008, Ben Finney wrote:
> Another purpose, that I've seen recently a few times, is people
> proposing *several* discrete options for a ballot, carefully
> phrasing them to be distinct in order to clarify the meaning of the
> vote's result.

If no one is going to rank those options highly, there's no purpose in
proposing them. I could see someone drafting them as an option for
someone else who planned on ranking them highly to actually propose
and second.
 
> According to Don's statement above, this is not a good reason to
> propose options. I disagree; I think it's commendable and in the
> spirit of his earlier statement (in the same message) to strive for
> clarity and precision in the ballot options.

Options that (almost) no one actually supports don't increase clarity.
Our voting system isn't a survey of developers; it's a means of
making decisions.


Don Armstrong

-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Ben Finney]

Russ Allbery  writes:

> Ben Finney  writes:
> > Don Armstrong  writes:
> 
> >> You should not be proposing or seconding an option that you don't
> >> plan on ranking first.
> 
> > This seems quite wrong. Why should one not carefully and precisely
> > phrase and propose an option that one does *not* agree with, in
> > order to get it voted on?
> 
> Why vote on something no one actually wants?

I don't know. I didn't know anyone was asking for that to happen.

> If it's a viable option, it will get enough seconds in its own
> right.

Yes, certainly.

I get the feeling you've excluded the middle between “propose an
option one does not plan on raking first”, and “propose an option
no-one wants on the ballot”.

> The only case where I could see it making sense to second options
> one personally doesn't support is if one believes for some reason
> that there is a huge disconnect between the people reading
> debian-vote and seconding proposals and the project as a whole, so
> huge that an option that would win in the larger vote doesn't have
> enough advocates reading debian-vote to get sufficient seconds. This
> seems unlikely to me.

Another purpose, that I've seen recently a few times, is people
proposing *several* discrete options for a ballot, carefully phrasing
them to be distinct in order to clarify the meaning of the vote's
result.

According to Don's statement above, this is not a good reason to
propose options. I disagree; I think it's commendable and in the
spirit of his earlier statement (in the same message) to strive for
clarity and precision in the ballot options.

Further, there may be other reasons that both you and I haven't yet
thought of. I think it's unwise to say pre-emptively that those are
“should not” reasons also, merely because they're not options the
proposer plans to rank first.

-- 
 \   “There is no reason anyone would want a computer in their |
  `\ home.” —Ken Olson, president, chairman and founder of Digital |
_o__)Equipment Corp., 1977 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 30, 2008 at 01:50:37AM +0100, Bernd Zeimetz wrote:
>>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
>> as well as resolutions against a shortening of discussion/voting
>> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
>> developers to sponsor the resolution.
>>  c) the definition of K gets erased from the constitution. [§4.2(7)]
>
>what I'd like to add here is something in the lines of
>
>d) If a resolution will affect an upcoming release which is already 
>   frozen, the resolution needs twice the number of sponsors as defined 
>   in a).
>
>This should help to avoid that some random people try to stop a release 
>in the latest moment if there's not a really good reason to do so. If 
>we want Debian to be used in business ("enterprise" *gasp*) 
>installations, we should at least be able to tell people when we're 
>about to release, without having them to fear a delay for months or 
>years due to a GR.

I disagree: Debian release when ready, not in time. Which is good!

If anyone creates a vote close to (expected) release, then they have a 
good reason to do that. Which we should not suppress by designing our 
rules to favor releasing "in time".


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklZfW8ACgkQn7DbMsAkQLgL9wCgimpsF0mEAjO8ZWqZE12riuqZ
4EsAnjuZ7gexFcSamZh9eV9zfY89YMHE
=+ttL
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Russ Allbery]

Ben Finney  writes:
> Don Armstrong  writes:

>> You should not be proposing or seconding an option that you don't
>> plan on ranking first.

> This seems quite wrong. Why should one not carefully and precisely
> phrase and propose an option that one does *not* agree with, in order to
> get it voted on?

Why vote on something no one actually wants?  It just makes the ballot
more complex and has the potential to add confusion and wording problems
for no gain.

If it's a viable option, it will get enough seconds in its own right.  If
it doesn't, it's so unpopular that there's no point in voting on it.

The only case where I could see it making sense to second options one
personally doesn't support is if one believes for some reason that there
is a huge disconnect between the people reading debian-vote and seconding
proposals and the project as a whole, so huge that an option that would
win in the larger vote doesn't have enough advocates reading debian-vote
to get sufficient seconds.  This seems unlikely to me.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[gregor herrmann]

On Tue, 30 Dec 2008 00:54:41 +0100, Joerg Jaspert wrote:

> I have felt for some time that the low requirement for seconds on General
> Resolutions is something that should be fixed. We are over 1000
> Developers, if you can't find more than 5 people supporting your idea,
> its most probably not worth it taking time of everyone. Various IRC
> discussions told me that others feel the same. 

I agree that raising the barriers would be a good idea.

Cheers,
gregor 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Tina Turner: The Best


signature.asc
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

 > 
> General Resolutions are an important framework within the Debian
> Project. Yet, in a project the size of Debian, the current requirements
> to initiate one are too small.
> 
> Therefore the Debian project resolves that
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]

not sure if we need floor(2Q) here, but at least floor(Q).

>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> as well as resolutions against a shortening of discussion/voting
> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> developers to sponsor the resolution.
>  c) the definition of K gets erased from the constitution. [§4.2(7)]

what I'd like to add here is something in the lines of

d) If a resolution will affect an upcoming release which is already frozen,
the resolution needs twice the number of sponsors as defined in a).

This should help to avoid that some random people try to stop a release in the
latest moment if there's not a really good reason to do so. If we want Debian
to be used in business ("enterprise" *gasp*) installations, we should at least
be able to tell people when we're about to release, without having them to
fear a delay for months or years due to a GR.


Cheers,

Bernd

- --
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklZcF0ACgkQBnqtBMk7/3mSWQCgqxtj+r+8utnDbSFVfisvwgLt
9YkAoIsQ3gKZnKjol2kbP0Yz9ysMtTqx
=PZiI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Ben Finney]

Don Armstrong  writes:

> 1: I'd be happier, though, if those proposing and seconding options
> would be more careful about the effects that their options may have,
> and be more vigilant about withdrawing options when more palletable
> options exist.

Absolutely agreed with this sentiment.

> You should not be proposing or seconding an option that you don't
> plan on ranking first.

This seems quite wrong. Why should one not carefully and precisely
phrase and propose an option that one does *not* agree with, in order
to get it voted on?

-- 
 \   “The cost of education is trivial compared to the cost of |
  `\ ignorance.” —Thomas Jefferson |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Don Armstrong]

On Tue, 30 Dec 2008, Joerg Jaspert wrote:
> Therefore the Debian project resolves that
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]
>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> as well as resolutions against a shortening of discussion/voting
> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> developers to sponsor the resolution.
>  c) the definition of K gets erased from the constitution. [§4.2(7)]

Whatever we decide to do should specifically modify the constitution;
that is

a) §4.2.1 is replaced with "The Developers follow the Standard
Resolution Procedure, below. A resolution or amendment is introduced
if proposed by any Developer and sponsored by at least floor(2Q) other
Developers, or if proposed by the Project Leader or the Technical
Committee."

b) §4.2.2.2 is replaced with "If such a resolution is sponsored by at
least floor(Q) Developers, or if it is proposed by the Technical
Committee, the resolution puts the decision immediately on hold
(provided that resolution itself says so)."

etc.

I'd also suggest alternatively, that we change K to be floor(Q), and
modify §4.2.1 to be 2K, §4.2.2.2 to be K, and §4.2.2.3 to be left
alone, which would have the same effect, but with fewer changes (and
we could define floor(Q) instead of assuming it to be known.)

Because quorum is 3Q, this would mean that any option will have enough
voters to conceivably win in an election. [I would also be ok with
K==1.5Q, and requiring at least K developers for each step.]

All that said, I'd be interested in seeing such a change made.[1]


Don Armstrong

1: I'd be happier, though, if those proposing and seconding options
would be more careful about the effects that their options may have,
and be more vigilant about withdrawing options when more palletable
options exist. You should not be proposing or seconding an option that
you don't plan on ranking first.
-- 
This message brought to you by weapons of mass destruction related
program activities, and the letter G.

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Stephen Gran]

This one time, at band camp, Kalle Kivimaa said:
> Joerg Jaspert  writes:
> >  a) The constitution gets changed to not require K developers to sponsor
> > a resolution, but floor(2Q). [see §4.2(1)]
> 
> This would mean that you need almost as many sponsors as is required
> for the quorum (2Q vs 3Q). I think that is too much. I think floor(Q)
> sponsors would be a more appropriate number.

That just means that the number of people who think the vote is even
worth having is not that different to the number of votes required to
make it valid.  That's probably not all that bad a thing, IMHO.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Kalle Kivimaa]

Joerg Jaspert  writes:
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]

This would mean that you need almost as many sponsors as is required
for the quorum (2Q vs 3Q). I think that is too much. I think floor(Q)
sponsors would be a more appropriate number.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Discussion: Possible GR: Enhance requirements for General Resolutions

[Joerg Jaspert]

Hi,

I have felt for some time that the low requirement for seconds on General
Resolutions is something that should be fixed. We are over 1000
Developers, if you can't find more than 5 people supporting your idea,
its most probably not worth it taking time of everyone. Various IRC
discussions told me that others feel the same. So here is a possible
proposal. Probably needs en_GANNEFF cleanup, and might need other
changes too, I try collecting them from replies.

As this will change the constitution, if we ever go and vote on it,
it will need a 3:1 to win. (see Constitution 4.1.2)

Oh, note. While this is written as a GR, this is a discussion proposal
only. I'm *not* calling for seconders with this mail. Thats also the
reason for the reply-to/mail-followup-to header going to -project,
please respect them.


General Resolutions are an important framework within the Debian
Project. Yet, in a project the size of Debian, the current requirements
to initiate one are too small.

Therefore the Debian project resolves that
 a) The constitution gets changed to not require K developers to sponsor
a resolution, but floor(2Q). [see §4.2(1)]
 b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
as well as resolutions against a shortening of discussion/voting
period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
developers to sponsor the resolution.
 c) the definition of K gets erased from the constitution. [§4.2(7)]

(Numbers in brackets are references to sections in the constitution).


Practical changes: Taking the definitions of the latest GR we had,

 Current Developer Count = 1021
 Q ( sqrt(#devel) / 2 ) = 15.9765453086705
 Quorum  (3 x Q )   = 47.9296359260114

this will mean that future GRs would need 30 other people to support
your idea. While that does seem a lot (6times more than now),
considering that a GR affects more than 1000 official Developers and
uncounted amounts of other people doing work for Debian, I think its not
too much. Especially as point b only requires 15 people, 3 times the
amount than now, in case there is a disagreement with the DPL, TC or
a Delegate.

-- 
bye, Joerg
Please, not the graphviz one again, I only just finished the therapy I had
to start after I read it the first time. I'm sure this one was written by
some sort of non-human entity. I would go for lawyers.


pgpdMKqVlawtH.pgp
Description: PGP signature

Re: Recommender systems (Re: Voting on messages: a way to resolve the mailing list problems)

[Filipus Klutiero]

Thanks for writing to my email address; I'm not subscribed to the list as you 
may have realized.

Le December 29, 2008 06:59:30 am MJ Ray, vous avez écrit :
> Filipus Klutiero  wrote:
> > MJ Ray wrote:
> > > I consider filtered indices, auto-responses, shadow lists of only
> > > "good" messages, highlighting, integration with db.debian.org and some
> > > of the other uses for this data to be recommendation systems.
> >
> > A filtered thread index as proposed is not a recommendation list.
>
> A filtered thread index as proposed could be a recommendation system
> according to both descriptions posted, although it depends how one
> interprets "suggest", "support" and so on, and how much
> personalisation one believes is needed to be a recommendation system.
I don't remember anything in this thread suggesting any level of 
personalisation, so I don't understand why you question the efficiency of 
message-voting due to concerns with recommender systems.

Even if you considered a filtered thread index as a recommendation list, your 
quote does not mean that recommender systems perform badly, it just means 
that some of the current systems have suboptimal aspects and proposes 
solutions. Furthermore, these aspects do not apply in the case of filtered 
thread indices.
>
> One can just as well see many drawbacks by looking at more general
> "collaborative filtering" research - or even out into more general
> population clustering work to see the reasons for the drawbacks - but
> it's a bit older, so less of it is online, so I didn't refer to it.

> I'm pretty sure that someone would react to the obvious problems in
> using an unpersonalised filtered thread index (which is a
> collaborative filter, isn't it?) by personalising it to make some sort
> of simple recommendation system, wouldn't they?
An unpersonalised filtered thread index wouldn't be an application of 
collaborative filtering.
According to Wikipedia:
> Collaborative filtering systems usually take two steps:
>
>1. Look for users who share the same rating patterns with the active
> user (the user whom the prediction is for). 
> 2. Use the ratings from those 
> like-minded users found in step 1 to calculate a prediction for the active
> user

It is possible that readers using an unpersonalised filtered thread index 
would want something personalized. I don't know, that's why I think data on 
the efficiency of CF in discussion systems would be interesting.

Since you seem to have misunderstood the meaning of CF, I assume the previous 
paragraph may be confused, but if you think it stands, please specify your 
concerns.


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian should focus on common grounds ....

[MJ Ray]

Osamu Aoki  wrote:
> I am sick of seeing too many votes/policy-discussion/... to force other
> volunteers to obey particular action patters.  Basic principle of this
> project should be more inclusive one and volunteer one.  It should not
> be a one of exclusion and enforcement.  Volunteer project should be
> based on coercion.

I don't think coercion is a good thing and I don't think that to ask
other volunteers not to do particular acts is the same as "to force
other volunteers to obey".  This is what I thought "Nothing in this
constitution imposes an obligation on anyone to do work for the Project"
meant.

So, the rest of the argument falls because of the above mistake in the
first step.  However, the conclusion:-

> Exclusion attitudes will only narrow our user/developer base and
> benefits none of us whatever opinion we have.  We should thrive to find
> common ground.

shows that you can state a good conclusion despite a bad step.  Maybe
that conclusion is a common ground?

Best wishes,
-- 
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: PATCH for spamass-milter to solve Debian list spam->bounce issue (Was:- Spamming the World through Open Debian Mailinglists....)

[Cord Beermann]

Hallo! Du (Michelle Konzack) hast geschrieben:

>In how many languages do you receive messages?
>
>I get german, english, french, spanish, portugues, arabic,  turkish  and
>persian messages
>
>Some times I get korean and chinese to because I have business contacts
>there.
>
>Tried to educate "spamassassin" for this kind of languages?

yes. we do that already. see
http://alioth.debian.org/projects/pkg-listmaster/ which represents our
running Amavis/SA-setup.

>> They are not set high enough apparently, otherwise I would not get
>> unsubscribed. See your archives, then you can easily count the number of
>> spams and the amount.
>
>I think the threshold is at 5 bounces and then you  have  to  confirm  a
>message that the message was rejected in accident...

No. please don't speculate about things. This only confuses people.

I tried to describe the kick-policy at
http://cord.de/blog/index.php?entry=entry080126-001137

I also understood that people want to have information about how many
bounces we counted for them. I'm just thinking about how to implement
that and will include that in the bounce-warning-message.

Cord


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Recommender systems (Re: Voting on messages: a way to resolve the mailing list problems)

[MJ Ray]

Filipus Klutiero  wrote:
> MJ Ray wrote:
> > I consider filtered indices, auto-responses, shadow lists of only
> > "good" messages, highlighting, integration with db.debian.org and some
> > of the other uses for this data to be recommendation systems.
> >   
> A filtered thread index as proposed is not a recommendation list.

A filtered thread index as proposed could be a recommendation system
according to both descriptions posted, although it depends how one
interprets "suggest", "support" and so on, and how much
personalisation one believes is needed to be a recommendation system.

One can just as well see many drawbacks by looking at more general
"collaborative filtering" research - or even out into more general
population clustering work to see the reasons for the drawbacks - but
it's a bit older, so less of it is online, so I didn't refer to it.
I'm pretty sure that someone would react to the obvious problems in
using an unpersonalised filtered thread index (which is a
collaborative filter, isn't it?) by personalising it to make some sort
of simple recommendation system, wouldn't they?

Nevertheless, I now wish I hadn't tried to skip the above step,
because it's resulted in this pedantic subthread.

Regards,
-- 
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: PATCH for spamass-milter to solve Debian list spam->bounce issue (Was:- Spamming the World through Open Debian Mailinglists....)

[Michelle Konzack]

Am 2008-12-27 16:55:58, schrieb Jeroen Massar:
> I already pointed this out the previous time I was complaining about
> getting unsubscribed. liszt.debian.org seems to run the same setup:
> postfix+spamassasin (though I dunno if you are using spamass-milter
> there, but you should otherwise); it seems also that my setup does know
> how to figure out that it is spam but yours doesn't.

In how many languages do you receive messages?

I get german, english, french, spanish, portugues, arabic,  turkish  and
persian messages

Some times I get korean and chinese to because I have business contacts
there.

Tried to educate "spamassassin" for this kind of languages?

You have to tune this pig as the hell.

> They are not set high enough apparently, otherwise I would not get
> unsubscribed. See your archives, then you can easily count the number of
> spams and the amount.

I think the threshold is at 5 bounces and then you  have  to  confirm  a
message that the message was rejected in accident...

> The biggest annoyance with the unsubscribes is that you don't even
> notice it because you don't get a notification of it (though on the side
> of the list, you are supposed to be dead then).

False, you get a message from the list system
I have a bunch of them...  But if you suppress  the  messages  from  the
mailer-daemon...  Oops!  (I have already written, that I had to whitlist
the E-Mail)

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Spamming the World through Open Debian Mailinglists (Re: lists.debian.org has received bounces from you)

[Michelle Konzack]

Hello Don,

Am 2008-12-27 03:31:45, schrieb Don Armstrong:
> If you don't want to deal with the occasional spam that gets through,
> then feel free to unsubscribe. Furthemore, the thresholds for
> automatic unsubscription are set fairly high anyway; the warning
> messages we send out are for your information only, as they often
> indicate mail misconfigurations at your end (or rarely, at ours.)

Please, is it possibel to include "threshold" infos in the info messge
from the listsoftware?

And of course, how many message went bounced?

I had to whitelist the sender of the bounces  since  my  courier  server
mailsystem has tried to bounce (!!!) it...  (my courier is  my  intranet
box which get the messages form the Internet using fetchmail and I think
that boincing is not realy what I want with some exceptions)

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Spamming the World through Open Debian Mailinglists (Re: lists.debian.org has received bounces from you)

[Michelle Konzack]

Hello Jeroen,

I am on 65 Debian Lists (or 147 in total) and from Debian I get per  day
less then 38 spams... and most are filtered by "spamassassin"  and  some
simple "procmail" rules...

Oh yes, the BTS (I am subscribed to any packages  installed  on  my  own
systems and those of my customers, hence 1586 in  total)  is  the  hell,
since some times I get over 700 per day.

However I am on those lists:

.ML_debian.68k
.ML_debian.alpha
.ML_debian.amd64
.ML_debian.arm
.ML_debian.cd
.ML_debian.changes
.ML_debian.curiosa
.ML_debian.custom
.ML_debian.debootloaders-yaboot
.ML_debian.debtags-devel
.ML_debian.desktop
.ML_debian.devel
.ML_debian.devel-announce
.ML_debian.devel-changes
.ML_debian.doc
.ML_debian.edu
.ML_debian.embedded
.ML_debian.events-eu
.ML_debian.firewall
.ML_debian.hppa
.ML_debian.i18n
.ML_debian.ia64
.ML_debian.initscripts-ng-devel
.ML_debian.isp
.ML_debian.jobs
.ML_debian.jr
.ML_debian.laptop
.ML_debian.legal
.ML_debian.libhid-discuss
.ML_debian.live
.ML_debian.mentors
.ML_debian.mips
.ML_debian.multimedia
.ML_debian.newmaint
.ML_debian.news
.ML_debian.news-french
.ML_debian.news-german
.ML_debian.perl
.ML_debian.pkg-mc-devel
.ML_debian.pkg-postgresql-public
.ML_debian.policy
.ML_debian.powerpc
.ML_debian.printing
.ML_debian.project
.ML_debian.qa
.ML_debian.release
.ML_debian.s390
.ML_debian.science
.ML_debian.security
.ML_debian.security-announce
.ML_debian.sparc
.ML_debian.ssh
.ML_debian.testing
.ML_debian.testing-changes
.ML_debian.user
.ML_debian.user-french
.ML_debian.user-german
.ML_debian.user-spanish
.ML_debian.user-turkish
.ML_debian.vote
.ML_debian.webapps
.ML_debian.women
.ML_debian.www
.ML_debian.x

It seems that there are 4 alioth list missing plus some very low traffic
lists where messages are already archived after 6 month...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Urgent respond

[Martin Dent]

I have a new email address!You can now email me at: mar_tinden...@ymail.com

Sir/Madam,

I’ve business to discuss with you, please contact me, for more details

Dent

- Martin Dent