Re: [Mailman-Developers] [Queries] Related to List Styles in mailman

2015-03-15 Thread prakhar joshi
hi,
 The advantage of first is that we will gonna have all the styles at a
single place and no need to call for the default page from other places as
we will gonna do in the second method. Here but we have to apply the
constraints on the default entries and not on other entries.
  On other hand in second point we will have a unify table with
same functionality for all the entries but we have to call the default
styles which will be at different place.

Thanks,

Prakhar Joshi
DA-IICT,Gandhinagar

On Mon, Mar 16, 2015 at 8:48 AM, Stephen J. Turnbull 
wrote:

> prakhar joshi writes:
>  > hi,
>  >  I am Prakhar Joshi (irc name :- _pjoshi). I have few things to
> discuss
>  > about the storage of new styles for the list that will be created
> through
>  > rest API. I think we should create a separate table for the list styles
> and
>  > there we can add the entries for the newly created styles in those
> tables.
>  > Now we have to work around for storing these default styles in the
>  > database. Here what I think is we can do it in 2 ways :-
>  > 1) We have two default entries in the table and can only have "GET"
>  > request for these two and "GET"/"POST" request for rest of the entries
> in
>  > the table.
>  > 2) We can have these 2 default styles out of the table and these 2
> can
>  > be called as they are now from their places in the web interface
> directly.
>
> What are the advantages and disadvanatages of the two approaches as
> far as you are concerned?
>
> Steve
>
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Reagarding A "Dashboard for Admins/Owners/Moderators"

2015-03-15 Thread Stephen J. Turnbull
Shreyas Lakhe writes:

 > Ihttps://moqups.com/srlakhe/weZugpFL

The "I" is a typo?

Note that Activity should be tri-state: approved, rejected, pending.
In the case of held messages, there may be more states (each reason
for holding mail could be treated as a separate state).

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] GSOC, Anonymous Lists

2015-03-15 Thread Stephen J. Turnbull
Pavan Koli writes:

(a generally good description of an approach to the problem)

 > hidden from him. But if someone tries to spam the mailing list,
 > that person can be caught by noting his anonymous id.

I'm not sure what use case you have in mind.  Why would a spammer post
to the anonymous list from the same address twice?  If subscription
(and posting) requires owner approval, such spamming is very rare
anyway.

 > 3.  I didn't come across a single mailing list for whistleblowers,
 > activists, or  people trading very sensitive information.

You won't.  They have alternative channels for transmitting
information, just like spies employed by governments or corporations.

 > Mail spoofing attempts can be stopped by encrypting mails,

Encrypted lists is a different use case.  You'd use digital signatures
in this case.

 > using PGP, but there is one problem. The person encrypting the mail
 > would have to share their public key with everyone on the mailing
 > list, which can be a tedious task as the mailing lists keep on
 > changing in size,

Key distribution in this case is easy.  Just post it to the mailing
list. :-)

 > and also mails can be leaked if public key falls into wrong hands.

This isn't a real use case.  Think carefully about your definition of
"wrong hands" in the context of "whistleblower".

 > I've come up with a solution for this, these mailing lists will be
 > kept in a very different category from others. Here when ever a
 > user will register, they'll have to also provide their public key.

This is in fact the same basic approach as a previous GSoC project
which hasn't been integrated yet.

 > Problem- The list manager has to be authentic, using their public
 > key list subscribers can verify their authenticity

I don't understand what you mean.

 > (Or I propose a public key for the list itself and then people can
 > use it to verify lists authenticity).

I think this is the right solution anyway.  One possibility would be
to use DKIM signature technology (RFC 6376, I think).

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators

2015-03-15 Thread Stephen J. Turnbull
Heshan Jayasinghe writes:

 > I am interested on your project "A Dashboard for
 > Admins/Owners/Moderators".I read your Documentation given about
 > these projectI want to know the path I should follow to contribute
 > your company.

Start by (re)reading the ideas page, paying specific attention to the
(new) section "Mentors Are Not Teachers".

Note that there is a lot of competition for this project.  (If I'm
counting correctly, yours is the 4th inquiry about it.)  You will get
more attention and are more likely to be accepted into GSoC as you
provide more of the planning and design ideas yourself, rather than
asking the mentors to do it for you.

By the way, a point of English usage: GNU Mailman is not a company (at
least in common use in American English).  It is a cooperative project
by volunteers.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators

2015-03-15 Thread Abhilash Raj
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Heshan,

On Monday 16 March 2015 01:35 AM, Heshan Jayasinghe wrote:
> Hi, I am Heshan Jayasinghe.I am 2nd year undergraduate in
> University of Moratuwa,Srilanka.I am an Open source developer and i
> really like to contribute your company in this GSOC 2015.In my
> university i did several android base applications.and  noSQL (RDF)
> based web applications.i am good at in front end development in
> HTML java script and ajax
> 
> I am interested on your project "A Dashboard for
> Admins/Owners/Moderators".I read your Documentation given about
> these projectI want to know the path I should follow to contribute
> your company.
> 
> I am looking forward for your reply

We need something more than "I am interested in project X" to reply
to. Please read the Ideas Page carefully, you'd find most of the
details to getting started there. In case you have questions, you are
welcome to post them here.


- -- 
thanks,
Abhilash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVBmx7AAoJEJ2bK6Bh0KZ8d9sP/1DqtVTvZKRzvwBSwj2z9acj
MVBJz2O7kNRmEq3kiH+p0uXDlGDDWlOC23Is58MnjtCVUX4rZfdr6indSTVrbxVs
H6zJ5JftUHv0RXxcS9dPaXLBnhN31pYwsFhuMmouYxQnZ+H0uLblek/AyFgyepa8
U4pqVudADuYXLdT2VICDx7JTnW/WERgwZHso+JiC/wxR/8OjaZ6sXp8U//hUoz49
ziZmUoxkCkCyM8HqbURnJTksttEOP2uuK3ZJXD80benuzAxERerhXYYzB3IaN5EB
Suxc5No7OzRZo2o/It8mhROcsapLUipkzawb1AMsuWe87SnZWWRBTCUpSoP2pdBs
eLh7jwJTr3twYf+Zn1cADNelerhLFlyce69uGQdi0PLJ2kbtSGFbIFkECZvC4fm5
VruuLN3m2pe84zfj7ygXLJ3xAeaJikgHC4jsYE4H2jqZ+QOm9UweJtAzuLxzckh5
+8y6ipcEFBqWNj/tcoVMvVnHWfcAhkr5/yu2m4bwUmCekeXU2mzbADV3Cn/g1UIe
4MgPyve3IfjHe9kNZA332QYiho0/dZYD86WXWWDfyxRqQOJf2gdJ+e0CEPWmmJm5
ctjXFC8YJSYFPpGMbhTBNvTlLMSISEK0Sx0gGetHq7Ns+13OqA2BwlIXV2/QxJwO
5qkOM0pixZYhUEY+TzNl
=aG2t
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Reagarding A "Dashboard for Admins/Owners/Moderators"

2015-03-15 Thread Shreyas Lakhe
Hi,

I have started working on making a more detailed prototype for the
"Dashboard for Admins/Owners/Moderators" project and I am thinking about
including the following features in
the admin interface:

1.General options(modifying list name , info, admins)
2.Password options(change the owners and administrators password)
3.Membership management(subscribe users, unsubscribe users with  mass
subscription/removal options)
4.Tending to pending moderator requests

The above mentioned points could be the base admin interface:
To allow the admins to manage multiple lists we could have:
1.add a new list
2.remove a list
(1 & 2 would be primary)
The other features would be grouped into two categories
1. a common listing of pending messages and requests for lists from the
last seven days
2. a list by list listing of the pending messages and requests , wherein
the above admin interface would work for individual   lists

Here is a link implementing some of the features.
Ihttps://moqups.com/srlakhe/weZugpFL

Suggestions on it are welcome.

Thanks,
Shreyas Lakhe
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] GSOC, Anonymous Lists

2015-03-15 Thread Pavan Koli
> >I have the same doubt.  You need to define "anonymous list".  In
> particular, specify who is, and who is not, supposed to be able to
>
>1.  See email addresses of subscribers.
> >2.  Figure out whether two posts are from the same person.
> as well whether you need to
> >3.  Ensure that subscribers' posts can't be spoofed.
>

These sites already are using anonymous lists
http://www.na.org.za/mailing-lists,
http://www.12stepforums.net/mailinglist.html,
http://www.e-aa.org/maillist.html.

>From the above I deduced that there can be three different use cases.

1. The list manager is a doctor, treating their patients. In this case
they'll be able to view patients e-mail ids. The e-mail ids will be mapped
to something like "anonymous_timestamp@domain". The list manager in this
case will have an interface where the anonymous ids will be listed along
with the real e-mail ids. This shall help them know whether two posts are
from the same patients or not. Also be able to communicate with patients,
if time arises.This list can be like an online support group where the list
manager is the doctor and the members are his patients.
Lists like http://www.12stepforums.net/mailinglist.html, will come under
that category.

2. The second use case can be when the list manager himself cannot be
trusted with the details, like suppose there is an online mailing list for
drug addicts to overcome their addiction, created by an ex-drug addict. But
we cannot trust our mail ids with this person, as we don't know clearly his
intentions. In this cases where the list manager cannot be trusted fully or
the list manager has no use, knowing my email id. Here the list manager
won't have any interface mapping anonymous ids with the original ids. But
can identify if two mails are by the same user or not by seeing the header-
From: anonymous id, on the two mails.
Lists like http://ottawana.org/, here members help each other, in such case
the list manager has no business knowing e-mail ids of members as he is not
offering any help, like the doctor in the previous case, so it would remain
hidden from him. But if someone tries to spam the mailing list, that person
can be caught by noting his anonymous id.

3.  I didn't come across a single mailing list for whistleblowers,
activists, or  people trading very sensitive information. Suppose there is
a group of whistleblowers and journalists, who are connected with this
mailing list. Obviously in this case the list manager won't be able to note
my real e-mail id, but can verify me using my public key(X.509
certificate), the mails in such cases would be regarding national
interests. Hence, there can be hacking attempts on the database or mail
spoofing attempts.

Hacking attempts can be made futile as the people registering for this
mailing list are definitely not going to register with their actual mail
ids, hence even if those stored mail ids are exposed. There is very less
chance of them getting caught.
Sites like (http://www.sendanonymousemail.net/, http://www.33mail.com/,
https://www.hushmail.com/) provide anonymous mail id creation.

Mail spoofing attempts can be stopped by encrypting mails, using PGP, but
there is one problem. The person encrypting the mail would have to share
their public key with everyone on the mailing list, which can be a tedious
task as the mailing lists keep on changing in size, and also mails can be
leaked if public key falls into wrong hands.

I've come up with a solution for this, these mailing lists will be kept in
a very different category from others. Here when ever a user will register,
they'll have to also provide their public key.
So now it will work in this way-
*User A will encrypt a message using his private key(PGP) and send on the
mailing list.

*On receiving a message, it will de decrypted by the public key provided
from the database.

*Now a sessions key will be generated, and it will be encrypted for
different users using their public keys. So suppose ABC is a sessions key
and user B, user C and user D are there. The sessions key will be encrypted
differently for different user using their public key.
(Although another way can be used is to encrypt the contents of the message
using the public keys of users, so every message will be encrypted
differently depending on the users public key. But in this situation there
can be a lot of time loss as the time taken would increase with the size of
the mailing list, but it can be implemented in cases where security is more
important than time, so it'll depend on further details like size of the
list)

*The message contents will be encrypted using the sessions keys to overcome
the time overhead associated as mentioned above.

*The users will first decrypt the sessions key using their private keys and
use it (session key) for decrypting the original message.

This can be thought as a safe method as people trying to spoof the messages
won't be able to do anything which is what I suppose.

Maintaining a mail archive 

[Mailman-Developers] [Queries] Related to List Styles in mailman

2015-03-15 Thread Stephen J. Turnbull
prakhar joshi writes:
 > hi,
 >  I am Prakhar Joshi (irc name :- _pjoshi). I have few things to discuss
 > about the storage of new styles for the list that will be created through
 > rest API. I think we should create a separate table for the list styles and
 > there we can add the entries for the newly created styles in those tables.
 > Now we have to work around for storing these default styles in the
 > database. Here what I think is we can do it in 2 ways :-
 > 1) We have two default entries in the table and can only have "GET"
 > request for these two and "GET"/"POST" request for rest of the entries in
 > the table.
 > 2) We can have these 2 default styles out of the table and these 2 can
 > be called as they are now from their places in the web interface directly.

What are the advantages and disadvanatages of the two approaches as
far as you are concerned?

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Fwd: GSoC 15

2015-03-15 Thread Stephen J. Turnbull
Please *always* include the project you're working on in the subject
and again in the text.

Shreyas Lakhe writes:

 > I have started working on making a more detailed prototype and I am
 > thinking about including the following features in
 > the admin interface:
 > 
 > 1.General options(modifying list name , info, admins)
 > 2.Password options(change the owners and administrators password)
 > 3.Membership management(subscribe users, unsubscribe users with  mass
 > subscription/removal options)
 > 4.Tending to pending moderator requests
 > 
 > The above mentioned points could be the base admin interface:
 > To allow the admins to manage multiple lists we could have:
 > 1.add a new list
 > 2.remove a list
 > (1 & 2 would be primary)
 > The other features would be grouped into two categories
 > 1. a common listing of pending messages and requests for lists from the
 > last seven days
 > 2. a list by list listing of the pending messages and requests , wherein
 > the above admin interface would work for individual   lists
 > 
 > Here is a link implementing some of the features.
 > Ihttps://moqups.com/srlakhe/weZugpFL

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Regarding Subscribe/unsubscribe policy for lists Edit

2015-03-15 Thread Stephen J. Turnbull
Ashish Kumar writes:
 > Hi,
 > 
 > I have been contributing to mailman since last two weeks. I found this bug
 > in the list "Subscribe/unsubscribe policy for lists" [
 > https://bugs.launchpad.net/postorius/+bug/1095552].
 > 
 > Can someone please tell me what's the current status of this bug and how
 > may I help in fixing it.

The status is whatever is posted to the bug.  The people who are
following the bug may be working on it but most likely are hoping to
hear somebody is fixing it.

If you're interested in working on it tell us what you propose to do
to fix it (even if at the moment that's limited to "studying postorius
code", which you should already have checked out ;-).

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Regarding Subscriber profile pages project

2015-03-15 Thread Stephen J. Turnbull
Ashish,

Aside from Abhilash's advice (to which +1), you should also look into
the Syster's implementation (IIRC it lives in github/systers
somewhere) of Mailman, which already implements a similar feature.
You can ask (politely! you're a guest there) on
systers-...@systers.org (you may need to subscribe) or on Freenode IRC
#systers-dev or #systers-soc.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] GSOC 2015: Seeking Information

2015-03-15 Thread Stephen J. Turnbull
Nakul Gulati writes:

 > After reading about mailman and going through the code base and
 > scope of different ideas, my interest align with the project
 > *Mailman Client written in Javascript* in particular. Hence, I'd
 > like to pursue it as part of GSOC 2015.

Sounds good to me.  See

http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt

for hints on how to write a proposal.

 > I would like to discuss further about the project.

There's nothing to discuss until you tell us what you think needs to
be done.  See Mentors Are Not Teachers on the wiki (which I just wrote
and posted):

http://wiki.list.org/DEV/Google_Summer_of_Code_2015

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] GSOC - Dashboard for Admins/Owners/Moderators

2015-03-15 Thread Stephen J. Turnbull
Yash Mehrotra writes:

 > *My Ideas - *
 > 1. One issue currently as mentioned is owners of multiple lists have to go
 > through all the pages for changes. I think we should show all the mailing
 > list's requests,subscriptions etc. all in one page.

This isn't a dashboard-level issue; this should be a facility at the
core level -- the core knows which lists the user is responsible for,
and what the pending tasks are for each.  Are you sure Mailman 3 +
Postorius doesn't have this capability already?

 > 2. The new list features should be opened from a different tab as a list
 > admin doesnt do this every day.
 > 
 > *The primary focus should be - to make it easy for an admin to do his daily
 > activities.*

I agree with the general statement, but are the new list operations
really a problem if displayed on the main dashboard?

 > 3. So, the index page will contain stuff mentioned on point 1, and the
 > there will be different pages for other stuff like - create/delete
 > list, view statistics ( see next point)

My experience with a non-web-based moderation system is that most
moderation/subscription requests can be judged from a one-line
display, and for more complex operations (eg, banning an apparently
abusive would-be subscriber) use Web 2.0 tech like Javascript
popup menus.  Of course they have to degrade gracefully if JS is
disabled, and even if CSS is disabled.  But the main interface
probably can include list creation/deletion and a few interesting
stats.

 > 4. We can also provide some basic statistics for a mailing list
 > like which user is most active, how many avg, mails are sent in a
 > day etc.

I don't understand why this belongs specifically on an admin
dashboard.  In most cases subscribers probably care more about it than
admins do.

 > 5. We also also give each list its individual page, so the admin
 > can do list specific functions like, say change settings ,

That's an ancient interface, and doesn't really come up to the
expectations people have when they hear "dashboard".  All your pending
tasks (including those you initiate like list creation) should be
available conveniently as soon as you log in, and as much as possible
which features are available should not depend on the currently.

 > ban user etc.

This will almost certainly turn out to be horrible UI.  Experience
shows that banning a user based on an abuse detected during moderation
or subscription approval, and so it should be available without
leaving the dashboard.

 > 6. One more cool feature would be to color code different types of things
 > for visual ease. Eg. Subscription requests can be color A. Held messages
 > can be color B. and so on. This will not only help the administrator but
 > also would visually good to look at.

Maybe.  On the other hand, maybe users will prefer to have the
tasks grouped (a group for subscription requests, a group for
moderation, a group for admin-initiated actions like list creation if
permitted, etc).  Maybe color coding will "look nice", but IMHO it's
unlikely to be a big efficiency enhancement compared to grouping.

 > I will add more stuff based on your feedback.

Sorry, that's not the way this works.  Part of GSoC to determine
requirements.  You tell us what you plan to do, we decide whether we
like it better than somebody else's proposal.  Most likely, if you
seem to have overestimated your productivity we'll tell you you can
cut back your proposal, and where to cut.  But if you propose
something trivial, mostly you'll get the simple comment "this is not
enough to be a good GSoC project."

A dashboard that gives convenient access to all tasks a user is
assigned seems like a GSoC-sized project to me (maybe bigger).

The main thing you need to add is a schedule.  See also
http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators

2015-03-15 Thread Heshan Jayasinghe
Hi,
I am Heshan Jayasinghe.I am 2nd year undergraduate in University of 
Moratuwa,Srilanka.I am an Open source developer and i really like to contribute 
your company in this GSOC 2015.In my university i did several android base 
applications.and  noSQL (RDF) based web applications.i am good at in front end 
development in HTML java script and ajax

I am interested on your project "A Dashboard for Admins/Owners/Moderators".I 
read your Documentation given about these projectI want to know the path I 
should follow to contribute your company.

I am looking forward for your reply


regards,
Heshan Jayasinghe.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] [Queries] Related to List Styles in mailman

2015-03-15 Thread prakhar joshi
hi,
 I am Prakhar Joshi (irc name :- _pjoshi). I have few things to discuss
about the storage of new styles for the list that will be created through
rest API. I think we should create a separate table for the list styles and
there we can add the entries for the newly created styles in those tables.
Now we have to work around for storing these default styles in the
database. Here what I think is we can do it in 2 ways :-
1) We have two default entries in the table and can only have "GET"
request for these two and "GET"/"POST" request for rest of the entries in
the table.
2) We can have these 2 default styles out of the table and these 2 can
be called as they are now from their places in the web interface directly.

I will really need to discuss these things. Any new suggestions are also
welcome.

Thanks,
Prakhar Joshi
DA-IICT,Gandhinagar
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


[Mailman-Developers] Some bare minimums for submitting patches (GSoC students take note)

2015-03-15 Thread Barry Warsaw
A quick note for GSoC students, although this can apply to anyone submitting
merge proposals to the core.  You really need to run the test suite before
submitting your branch.  If the test suite fails, I am going to mark your
branch 'needs fixing' and move on.

Of course, ideally your branch would include any tests needed to illustrate
the problem too.  If there are no tests, then it's a red flag to me that maybe
the fix doesn't actually fix the problem.

One technique I use when looking at your branch is to unapply the fix and just
run your tests.  If I see a failure, that's a *good* thing because I then
expect to reapply your fix to see the failure go away.  This is just an
extension of test driven development (TDD) of which I'm a fan.  As we say,
"untested code is broken code".

Cheers,
-Barry


pgpekIRRK3AVf.pgp
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] full anonymisation approach

2015-03-15 Thread Stephen J. Turnbull
Rashi Karanpuria writes:
 > 
 > Sorry, I forgot to add the footnotes for the previous mail on this thread.
 > 
 > footnotes:
 > [1] http://counseling.caltech.edu/general/InfoandResources/Shyness
 > [2] The Internet: Biographies (google books)


OK, Thanks.  I've been going through mail in order due to connectivity
problems.  Didn't see this before the last message.  All cool on the
references!


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] full anonymisation approach

2015-03-15 Thread Stephen J. Turnbull
Rashi Karanpuria writes:

 > > Aside: I think if you actually use such a list you'll discover that
 > > most "shy" people are far more afraid of being flamed than they are of
 > > social stigma *outside* of the discussion thread.  OTOH, it is likely
 > > to bring out the worst in trolls.  IMHO YMMV etc.

 > We can't overlook the fact here that shy people and most of the
 > others facing one social stigma or other do benefit from anonymous
 > conversations and 12-step program lays focus on such
 > websites.

I'm not overlooking the possibility, and if you want to use the word
"fact" you should cite serious research (or reliable textbooks that
cite the serious research).  Psychology (especially clinical) is a
field that's rife with real crap (see Kahnemann _Thinking Fast and
Slow_ for an introduction).  For GSoC purposes, I'm willing to assume
that there are benefits for the use case you describe.

What you're overlooking is that you use words like "anonymous" and
"conversation" without specifying them properly.  Is an "anonymous"
mailing anonymous enough for the users?  How about the FUD effect if
there is a public incident where a stalker manages to identify a
victim through your anonymous list implementation?  The design of your
implementation is going to depend sensitively on the answers you give
to these questions.

 > I plan on keeping list identity of a poster constant in a thread,
 > i.e., I generate a new list identity for a first post to a new
 > thread.  Reasons of this were mentioned by me in
 > http://www.mail-archive.com/mailman-developers%40python.org/msg15283.html

OK.  Remember that identifying threads is inaccurate.

I wonder if it would be useful to have a feature where a user could
change her ID, or link an old ID to a current one.  (That's not a
requirement for this product, but IMHO you should consider the
possibility with designing modules/internal APIs.)


 > So, we will be using the In-Reply-To header of the mail to map the
 > messages to their respective threads.  Hence tweaking with subject
 > will not be treated as a new thread as long as the user is using
 > Reply-To feature, which is essential while conversating in a
 > thread. Also using references won't be reliable as after the length
 > of thread becomes large few entries from the references are dropped

I disagree.  You should use both.  The RFC for References does not
specify which, if any, References are to be kept, but most
implementations keep all, most of the others I've seen keep the most
recent.  If any are kept, they help verify the members of the
predecessor set, even if the order can't be fully relied on.

 > > Speaking of "originator", what do you propose to do about
 > > non-subscribers who are CC'd?
 > 
 > We can remove the CC and BCC fields as if sent to a non-subscriber
 > using CC the original id of the originator will be displayed and if
 > a subscriber is CC'd then the mail bounces as posting address is a
 > fake address.

I don't understand what you mean by "posting address is a fake
address."

 > The originator can use one of the many available anonymous mailer
 > services for personal anonymous mails.

You absolutely cannot rely on originators to be clueful about this (in
fact, isn't that your original motivation: the obvious answer is "if
you want to be anonymous on a list, use an anonymizer service").
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9