Re: [Launchpad-dev] Should team membership requests expire?
On Tue, Oct 18, 2011 at 12:51 AM, Robert Collins robe...@robertcollins.net wrote: If that's not the case, please explain how this invariant can now be broken. One possible explanation is that the situation is more tight: 'preferred non-hidden email address' : some of our email use cases are showing it to other users, and for that we need non-hidden. There is also some Science Fiction on bounce processing. One day we might catch bounces and flag dead email addresses as old. That doesn't happen yet of course. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-17 21:07, Francis J. Lacoste wrote: This is an affirmation that I've seen mentioned a couple of time recently, but I cannot assert his truth value. In my understanding, this is still a myth. Launchpad users always have a preferred email address. Teams might not have one, as person records that we imported but nobody activated. But as soon as a user logs in Launchpad, and thus become a user, they have a preferred address. As I recall there were two separate problems: one was with code that wasn't prepared to accept teams as persons. The other was with cases where a preferred email address is disabled. How that could happen, I don't remember. But if an email address can be invalidated, deleted, or disabled, what's to say there will always be a preferred email address to replace it? Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 10/18/2011 10:15 AM, Jeroen Vermeulen wrote: On 2011-10-17 21:07, Francis J. Lacoste wrote: This is an affirmation that I've seen mentioned a couple of time recently, but I cannot assert his truth value. In my understanding, this is still a myth. Launchpad users always have a preferred email address. Teams might not have one, as person records that we imported but nobody activated. But as soon as a user logs in Launchpad, and thus become a user, they have a preferred address. As I recall there were two separate problems: one was with code that wasn't prepared to accept teams as persons. The other was with cases where a preferred email address is disabled. How that could happen, I don't remember. But if an email address can be invalidated, deleted, or disabled, what's to say there will always be a preferred email address to replace it? The status of the preferred email address is set to NEW when the user deactivates himself or an admin suspends a user. There were many cases in the past where suspended users were set back to active, but that does not restore the email address. This lead to several insane cases where the user could log in, but the profile was crippled. The correct path to restore the profile was to set the account status is deactivated to signal that the user can login and the profile restored. The email restoration process is ambiguous since Lp lost login/SSO. The reset password process does not exist. Lp implicitly chooses a preferred email address for deactivated/unactivated profiles during Lp's confirmation that the user authenticated. Teams are not deactivatable. Users delete them through a merge action (merge with ~registry). Email addresses are deleted during a merge. Teams may only have two email addresses, one to contact the team and one for a mailing list. Extra email address are deleted when the contact address is set. If the contact address is the mailing list address, the team can only have the one email address. -- Curtis Hovey http://launchpad.net/~sinzui signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 11-10-17 12:22 AM, Jeroen Vermeulen wrote:
On 2011-10-13 15:06, Robert Collins wrote:
Curtis script expunges dangling team join requests; expiring them
would involve notifications ('sorry your request was not replied to'),
and that would be bogus if e.g. the person had been deleted (or
alternatively merged into someone in the team). Neither case can
happen if the person merge bug is fixed.
It was stupid of me to ignore notifications. But is this really a case
of membership request expiry is harder with the broken data still in
place, or is it actually notifying users of anything related to
membership requests is harder with the broken data still in place?
ISTM the notification code needs to be robust against this sort of thing
as a matter of necessity. Wasn't similar robustness built in back when
we realized that users don't always have preferred email addresses?
This is an affirmation that I've seen mentioned a couple of time
recently, but I cannot assert his truth value. In my understanding, this
is still a myth. Launchpad users always have a preferred email address.
Teams might not have one, as person records that we imported but nobody
activated. But as soon as a user logs in Launchpad, and thus become
a user, they have a preferred address.
If that's not the case, please explain how this invariant can now be broken.
--
Francis J. Lacoste
francis.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-13 15:06, Robert Collins wrote:
Curtis script expunges dangling team join requests; expiring them
would involve notifications ('sorry your request was not replied to'),
and that would be bogus if e.g. the person had been deleted (or
alternatively merged into someone in the team). Neither case can
happen if the person merge bug is fixed.
It was stupid of me to ignore notifications. But is this really a case
of membership request expiry is harder with the broken data still in
place, or is it actually notifying users of anything related to
membership requests is harder with the broken data still in place?
ISTM the notification code needs to be robust against this sort of thing
as a matter of necessity. Wasn't similar robustness built in back when
we realized that users don't always have preferred email addresses?
Jeroen
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-14 19:48, Matthew Revell wrote: So, as for adding expiry to team memberships: our feature work is unlikely to give us an excuse to add such a feature any time soon and it's not a critical issue for a maintenance squad to tackle. If someone were able to add this expiry outside of either feature or maintenance time, I think it could be nice to have but I'd want us to know more about why people let such requests languish. Compromise: send out reminders for existing cases, hint at a possible future expiry regime, but don't implement expiry yet. See what responses we get, and from which party. I think we'll shake loose a lot of untended teams and moot membership requests. We'll also stir some team admins into action. The Follow idea sounds good. Some membership requests seem to fulfill an almost ritualistic need. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 12 October 2011 11:07, Jeroen Vermeulen j...@canonical.com wrote: And I wonder: if a team membership request has not been approved in a year, say, doesn't that amount to a denial of the request? Shouldn't we treat it as one? Considering this aside from the corrupted requests we have, I think an expiry is a good idea provided we bear in mind the principle of It's not our data that Rob mentioned. I think we can do that in a few ways, such as: * make expiry an opt-in at the team level * we send a reminder email to the team admins a week or so before a request is about to expire, to give them a chance to deal with it themselves. If we decide it's something we want to work on, I'd like to talk to some of the owners of teams that have many outstanding membership requests. I like Martin's suggestion of a text field that lets people say why they're applying. I also agree that we need to better understand why and how people use teams before we start making changes. I have a hunch that, should we do a study, we'd find three broad reasons for joining a team: * to get some kind of privs -- e.g. push rights for a project's trunk branch * to participate in a mailing list * to say, I think this is cool and would like to be associated with it and, possibly, would like to hear about it from time to time. We could handle those last two separately from teams and not really lose anything. The likelihood is that we won't be touching mailing lists for the foreseeable future but the I want to associate myself with this/get info about this is something that we could handle as part of our Dashboards and Walls feature. If we offer people the ability to follow a project, person or team, they'll get updates on their dashboard/wall about that item; a bit like Facebook pages and subscriptions, right? Maybe that'll help clear up some of the hanging membership requests we get, by steering them to another place. So, as for adding expiry to team memberships: our feature work is unlikely to give us an excuse to add such a feature any time soon and it's not a critical issue for a maintenance squad to tackle. If someone were able to add this expiry outside of either feature or maintenance time, I think it could be nice to have but I'd want us to know more about why people let such requests languish. Cheers. -- Matthew Revell Launchpad Product Manager Canonical https://launchpad.net/~matthew.revell ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On Thu, Oct 13, 2011 at 3:29 PM, Jeroen Vermeulen j...@canonical.com wrote:
On 2011-10-13 03:14, curtis Hovey wrote:
A similar fix was made for answer contacts a few months ago. The fix is
almost identical to the script I have used to fix vestigial data. I am
attaching my script
This looks suspiciously like a complete solution to the problem of the
broken membership requests. Is it meant to be?
Also, the part for team membership requests/invitations looks very simple.
If I wanted expiry for old requests, I'd just replace the where
conditions pertaining to account status with one on the record's age.
But Robert tells us that the problematic team membership records are harder
to clean up than regular old requests.
What am I missing?
Curtis script expunges dangling team join requests; expiring them
would involve notifications ('sorry your request was not replied to'),
and that would be bogus if e.g. the person had been deleted (or
alternatively merged into someone in the team). Neither case can
happen if the person merge bug is fixed.
-Rob
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 10/12/2011 10:29 PM, Jeroen Vermeulen wrote: On 2011-10-13 03:14, curtis Hovey wrote: A similar fix was made for answer contacts a few months ago. The fix is almost identical to the script I have used to fix vestigial data. I am attaching my script This looks suspiciously like a complete solution to the problem of the broken membership requests. Is it meant to be? Also, the part for team membership requests/invitations looks very simple. If I wanted expiry for old requests, I'd just replace the where conditions pertaining to account status with one on the record's age. But Robert tells us that the problematic team membership records are harder to clean up than regular old requests. What am I missing? When a team or person is merged membership requests should be deleted. They were not because merge often timedout. There is a large category of bad data left behind in merges, some maybe fixed in the code, but the data is still in the db. When you see a merged user in a portlet, or is a feedback request, you can be certain it is bad data. The expiration membership request issue described here is a work around for for another defect in Lp. We need to fix the defect instead of adding another feature. It is easier to fix the defect with a garbo job than it is to add new tests for a new feature. Last year a user requested a membership and merged profiles in the same day. Both the old and the new profile had the same display name. The team admin could not tell them apart. Lp generated a 404 for one link and a proper page for the other. -- Curtis Hovey http://launchpad.net/~sinzui signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Should team membership requests expire?
Due to a problem with the person-merging code, it seems we have some team membership records that can't be removed. Here's a particularly annoying case where membership requests can't be approved or denied: https://answers.launchpad.net/launchpad/+question/173909 As things stand, these requests are permanent garbage. Very annoying for team admins. And I wonder: if a team membership request has not been approved in a year, say, doesn't that amount to a denial of the request? Shouldn't we treat it as one? I think that makes sense in itself, but it could also make this particular bug a bit more bearable. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-12 17:07, Jeroen Vermeulen wrote: And I wonder: if a team membership request has not been approved in a year, say, doesn't that amount to a denial of the request? Shouldn't we treat it as one? The user who is running into the problem followed up with a noteworthy comment: «I have a backlog of unhandled requests which I'm currently reviewing. Some of them are from early 2009. The policy in our team is to wait 3 months for feedback after sending a mail with guidelines. Expiring these applications right now would not be very good for us.» Two generally applicable notes there: 1. A year seems orders of magnitude more than you'd need, but for this team, the margin is much smaller. 2. Before you make a change that will affect masses of legacy data: Think! How might it affect users who are counting on the old behaviour? Ask around. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On Wed, Oct 12, 2011 at 3:37 PM, Jeroen Vermeulen j...@canonical.com wrote: Due to a problem with the person-merging code, it seems we have some team membership records that can't be removed. Here's a particularly annoying case where membership requests can't be approved or denied: https://answers.launchpad.net/launchpad/+question/173909 As things stand, these requests are permanent garbage. Very annoying for team admins. And I wonder: if a team membership request has not been approved in a year, say, doesn't that amount to a denial of the request? Shouldn't we treat it as one? I think that makes sense in itself, but it could also make this particular bug a bit more bearable. Jeroen Hello! I think it would be a nice idea to have team admins be able to set a certain number of days or months after which an application is either automatically rejected or expired (like we do for bugs). This makes things cleaner and more flexible for all teams that use Launchpad. Cheers Nigel ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-12 18:16, Nigel Babu wrote: I think it would be a nice idea to have team admins be able to set a certain number of days or months after which an application is either automatically rejected or expired (like we do for bugs). This makes things cleaner and more flexible for all teams that use Launchpad. That does sound nice. And as you said on IRC, “a year” is arbitrary. But how often can a team owner predict exactly what to do should they ever be unable to attend to requests for precisely, say, 18 days? It's still arbitrary, just with a knob for people to twiddle and argue over. Is arbitrary so bad? Maybe not. Expiry is a way to deal with breakdowns in management by humans, not a substitute for it. If we draw a visible line at one year, maybe the humans will be stimulated to do better. A 3-year backlog of requests, mostly no longer relevant, certainly won't stimulate them. Finally, but most importantly: if we want to do this, it had better be as simple as it can be or we'll never get around to it. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On Wed, 12 Oct 2011 17:07:49 +0700, Jeroen Vermeulen j...@canonical.com wrote: And I wonder: if a team membership request has not been approved in a year, say, doesn't that amount to a denial of the request? Shouldn't we treat it as one? It sounds reasonable to me, provided you can send the requeust again later if it expired. If someone misses the mail and comes back a year and a day later to ask about it not allowing them in the team would be annonying. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
Whats the bug number? It shouldn't be low :) [because it creates bad data that confuses our users and causes them to come ask us questions, taking up their time and ours]. On the 'should we expire' side - We have a guiding principle that Launchpad is the custodian of peoples data, not the owner. A mandatory fixed expiry date seems (to me) to be in tension with that. As Nigel says though, a configurable setting might be considered a feature. Note that an expiry mechanism intended to deal with this corrupt data would be more complex than one that has good data, so I think an expiry system is a different work item to fixing the corrupt data (and the cause of the corruption). -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 10/12/2011 06:07 AM, Jeroen Vermeulen wrote: Due to a problem with the person-merging code, it seems we have some team membership records that can't be removed. Here's a particularly annoying case where membership requests can't be approved or denied: https://answers.launchpad.net/launchpad/+question/173909 As things stand, these requests are permanent garbage. Very annoying for team admins. https://bugs.launchpad.net/bugs/58138 Yes, this should be a garbo job to handle deactivate, suspended, and merged persons. There is never enough time to implement a fix. A similar fix was made for answer contacts a few months ago. The fix is almost identical to the script I have used to fix vestigial data. I am attaching my script -- Curtis Hovey http://launchpad.net/~sinzui -- Update membership and delete subscriptions for merged, deactivated -- and suspended users. This script clean all data that was not updated -- by the status change that is still visible in the UI. -- Proposed or Invited member that is merged or deactivated; -- make declined (6) -- staging 85 UPDATE TeamMembership SET status = 6 WHERE id in ( SELECT TeamMembership.id FROM TeamMembership JOIN Person ON TeamMembership.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) AND TeamMembership.status in (1, 7) ) ; -- Approved or Admin member, make deactivated (4) -- Suspended users are not removed because some bots like ~katie must -- be members of a team. -- staging 44 UPDATE TeamMembership SET status = 4 WHERE id in ( SELECT TeamMembership.id FROM TeamMembership JOIN Person ON TeamMembership.person = Person.id JOIN Account ON Person.account = Account.id WHERE Person.merged IS NOT NULL OR ( Account.status = 30 AND TeamMembership.status in (2, 3)) ) ; -- Delete bugsubscriptions of deactivated and suspended users. -- staging 10544 DELETE FROM BugSubscription WHERE id in ( SELECT BugSubscription.id FROM BugSubscription JOIN Person ON BugSubscription.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete structuralsubscriptions of deactivated and suspended users. -- staging 289 DELETE FROM StructuralSubscription WHERE id in ( SELECT StructuralSubscription.id FROM StructuralSubscription JOIN Person ON StructuralSubscription.subscriber = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete SpecificationSubscription of deactivated and suspended users. -- staging 14 DELETE FROM SpecificationSubscription WHERE id in ( SELECT SpecificationSubscription.id FROM SpecificationSubscription JOIN Person ON SpecificationSubscription.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete BranchSubscription of deactivated and suspended users. -- staging 167 DELETE FROM BranchSubscription WHERE id in ( SELECT BranchSubscription.id FROM BranchSubscription JOIN Person ON BranchSubscription.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete ArchiveSubscriber of deactivated and suspended users. -- staging 3 DELETE FROM ArchiveSubscriber WHERE id in ( SELECT ArchiveSubscriber.id FROM ArchiveSubscriber JOIN Person ON ArchiveSubscriber.subscriber = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete AnswerContact of deactivated and suspended users. -- staging 3 DELETE FROM AnswerContact WHERE id in ( SELECT AnswerContact.id FROM AnswerContact JOIN Person ON AnswerContact.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- Delete POSubscription of deactivated and suspended users. -- staging 0 DELETE FROM POSubscription WHERE id in ( SELECT POSubscription.id FROM POSubscription JOIN Person ON POSubscription.person = Person.id JOIN Account ON Person.account = Account.id WHERE Account.status in (30, 40) ) ; -- -- merged teams -- -- Update membership and delete subscriptions for merged teams -- This script clean all data that was not updated -- by the status change that is still visible in the UI. -- Proposed or Invited member; make declined (6) -- staging 43 UPDATE TeamMembership SET status = 6 WHERE id in ( SELECT TeamMembership.id FROM TeamMembership JOIN Person ON TeamMembership.person = Person.id WHERE person.merged IS NOT NULL AND TeamMembership.status in (1, 7) ) ; -- Approved or Admin member, make deactivated (4) -- staging 6 UPDATE TeamMembership SET
Re: [Launchpad-dev] Should team membership requests expire?
On 10/12/2011 06:07 AM, Jeroen Vermeulen wrote: Due to a problem with the person-merging code, it seems we have some team membership records that can't be removed. It is low because we did not have infrastructure in place to address this kind of problem for many years. We did not have a garbo system and we did not have async merging until June. This is the cluster of issues I keep talking about, they are the merge-deactivate bug tag. As you say, we can to these after we solve the critical issues, maybe in 2013. -- Curtis Hovey http://launchpad.net/~sinzui signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-13 02:53, Robert Collins wrote: On the 'should we expire' side - We have a guiding principle that Launchpad is the custodian of peoples data, not the owner. A mandatory fixed expiry date seems (to me) to be in tension with that. As Nigel says though, a configurable setting might be considered a feature. I don't see that tension here. As with an incomplete bug report (which we expire in 60 days) or a pending translations upload (which we delete eventually), a membership request is not a particular person's data. People produced it, but it's meaningless without continuation by whoever is in charge. Approval or rejection is effectively consumption of the data, not alteration. A fixed expiry period states that you need to act on a request within a given time if you want to prove that there's still an interested human in charge at all. If there isn't, it's not people's data. The request is effectively un-owned wastepaper; at best it deserves to be renewed. We might as well say loudly and clearly that Launchpad will see it that way after a given period. Note that an expiry mechanism intended to deal with this corrupt data would be more complex than one that has good data, so I think an expiry system is a different work item to fixing the corrupt data (and the cause of the corruption). This is something I haven't looked into; in what ways is it more complex? (Having a quick look at Curtis' message in this thread… …There's some SQL there that looks like it wouldn't even notice a difference between the corrupt data and regular ignored requests. I'll follow up there with my questions.) Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-13 03:14, curtis Hovey wrote: A similar fix was made for answer contacts a few months ago. The fix is almost identical to the script I have used to fix vestigial data. I am attaching my script This looks suspiciously like a complete solution to the problem of the broken membership requests. Is it meant to be? Also, the part for team membership requests/invitations looks very simple. If I wanted expiry for old requests, I'd just replace the where conditions pertaining to account status with one on the record's age. But Robert tells us that the problematic team membership records are harder to clean up than regular old requests. What am I missing? Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
I think expiry makes sense. These dangling accounts or dead requests ought to expire without needing to wait for a year. https://answers.launchpad.net/launchpad/+question/173909 I wish there was a 'reason' field on team membership requests because a large fraction of them seem to be mysterious, from people with no previous involvement or contact with the project, who perhaps are confused about why they're clicking it. Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 2011-10-13 11:17, Martin Pool wrote: I wish there was a 'reason' field on team membership requests because a large fraction of them seem to be mysterious, from people with no previous involvement or contact with the project, who perhaps are confused about why they're clicking it. My impression has been that very often, people just assume that they need to join up somewhere first in order to get involved in any way. I've also heard it said that many people just to want to be seen as being members of projects, even if they don't intend to contribute. Maybe that's true, maybe it's too harsh; I do wonder if perhaps some people see this as a Like button. Another hypothesis: could some of these people be hoping there's more about the project that they won't see until they join up? Especially without wiki hosting, people may be under the impression that they're only getting a limited view. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Should team membership requests expire?
On 13 October 2011 16:30, Jeroen Vermeulen j...@canonical.com wrote: On 2011-10-13 11:17, Martin Pool wrote: I wish there was a 'reason' field on team membership requests because a large fraction of them seem to be mysterious, from people with no previous involvement or contact with the project, who perhaps are confused about why they're clicking it. My impression has been that very often, people just assume that they need to join up somewhere first in order to get involved in any way. I've also heard it said that many people just to want to be seen as being members of projects, even if they don't intend to contribute. Maybe that's true, maybe it's too harsh; I do wonder if perhaps some people see this as a Like button. Another hypothesis: could some of these people be hoping there's more about the project that they won't see until they join up? Especially without wiki hosting, people may be under the impression that they're only getting a limited view. I think any of those are possible. We could do some kind of user study to find out. Or, we could add a freeform field and see what people type in it, which would also help the team owners decide if they ought to let them in. Or, we could deemphasize requests to join a team. I wonder how many requests are accepted? ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
