proposal: earning rewards for new contributors

[smoe]

Hello, the WCG allows you to earn badges for bringing new contributors to the project. This is a splendid idea to reward the spreading of the science. My personal preference would be to have not the number of (fake?) email addresses rewarded but to reward the factual credits that have been accumulated by the acquired new contributors.
Either way, it would be nice to have such a concept integrated in the regular BOINC server code. Once could discuss if any such "I heard about the (BOINC) project from" interlinking of participants should be implemented across projects or if only within a given project this information should be stored and used. My personal prefernce is to have it implemented only on the project level.

[Ageless93]

You mean something like https://boinc.berkeley.edu/trac/wiki/BadgeDoc ??

[smoe]

Except that these should not be about one's own contribution but about the contributions of those that one has persuaded to contribute to the science.

[sekerob]

Recruitment badge levels at WCG have to be 'maintained'. If a 'recruit' has not returned a result for I think 30 days, they drop off from the 'active' count towards which the badge level is kept up, to prevent someone being luded into creating temporary accounts.

[smoe]

Ah, that helps. It has the downside of not being monotonous, though, i.e. you'd have to take a badge away from someone who may have genuinely done well, e.g. at a public astronomy event or so. Maybe we can have both? A badge for all the social interactions (number of contacts brought to a project) and a sum of RACs by those new members.

[smoe]

@davidpanderson - would you invite the community (or me?) to send pull requests implementing this feature? Any preference about how to implement it? To me it is an additional attribute to the friendships that are interlinking the participants already. A major difference to friendships is that the "learnd about project by" attribute is not symmetrical.

[tristanolive]

This seems like a good feature, let's mark it for review by committers (per the Development Workflow process) to see if it gets approval or if anyone has any suggestions on implementation.

[davidpanderson]

What would the UI look like, i.e. when and how would the new volunteer identify who recruited them?

[smoe]

I would have it on the web. I suggest a "introduced me this BOINC project" checkbox to an already established friendship. Only the introducee would check that. Only one introducer should be allowed per individual, even though there could be situations in which multiple individuals get additional folks to join at the same time, to keep things simple. And I suggest to have this box already offered at the time the friendship is requested.

At first I thought that I would not require the introducee to have established the account after the introducer as there are many projects that I introduce people to that have never seen any contributions of mine at the time of the recruitment. At a second though, well, why should the recruitee to BOINC not introduce his/her recruiter to a new project even though the recruiter to BOINC already new about it but was not as excited as the recruitee about it, so, well, maybe it is a good idea to have the time of account creation as an indication for the direction.

Concerning the "how would the new volunteer identify who recruited them", this should be in analogy to how friends find themselves today. Maybe recruiters have their user ID on a small paper in a more anonymous setting. But for most contacts I presume that one can just ask back about it once one has signed up.

[sirzooro]

Removal of recruitment badges when someone does not return results for 30 days has its pros and cons. On one hand it protects against creation of temporary accounts just to get them, However downside of this is that someone may have change his/her mind after contributing some significant amount of work to project and decide to go away, and in such case recruiter will lose badge. I propose a bit different approach - when recruited person will contribute some significant amount of work to project (e.g. 1 month of computing, or x GFLOPS), he/she still will be counted towards recruitment badge, no matter if he/she is still active at project or not.

[smoe]

I would opt for the simplest possible implementation, whichever that may be. My vote goes to counting up the credit of these special friends. No removal. No special conditions like minimal contribution time. No head count.

[sirzooro]

Yes, no removal is better than removal if someone stops contributing. But if BOINC people would decide to go the latter way, there should be some extra rule like one proposed by me. Otherwise this will be like existing RAC badges, they come and go, and people do not value them much.

[smoe]

Badges are a follow-up discussion in my mind. If we knew (we don't as of today) how much RAC your recruitees have in total, then you'd have an indication about important your recruitment efforts are at any given moment or if you need to remind someone to get active again/fix a problem. The total credits of your recruiters are an indication of your total success which may optionally also be rewarded with badges.

[TheAspens]

Sorry for being late to this conversation. Here are my thoughts (some of this based on our experiences at WCG):

Easiest implementation:

How to indicate who recruit/set up the recruiting relationship:

• Provide a link that a recruiter can use to share on the web that contains your userid. If someone joins using this link they will automatically be set up to be recruited by you
• For a new user that doesn't have a recruiter designated yet offer a box on the account page (home.php) that says something to the effective of "Recruited by" and the placeholder for the input field would say something like "Userid of recruiting user" (text needs work)
• If the recruited by relationship has been established, then it should display the name of the user who recruited them in a display only field (maybe a link to that user). There should also be a 'remove' button that lets them remove the recruiting relationship.

How to display the users someone has recruited:

• create a page recruits.php that simply lists the people who have indicated that you recruited them. It could show some basic stats like total credit and team if you'd like
• there should be an indication if the user counts toward your total recruits or not (see below)
• this page should diplay a count of their recruits and their current badge

Which recruits count toward the badge?

• If total credit >= 1 then count them

Reasoning and potential issues:

• Keep it simple so that it is easy to implement
• Once someone gets credit for recruiting someone, let them keep the acknowledgement for the account even if it goes dormant. Otherwise someone has to work hard just to maintain their badge and will eventually get discouraged and give up working on this badge.
• Don't limit how long people have to setup or change the relationship. Although this can lead to people occasionally doing something unusual, it avoids having to get project admins involved in 'fixing' things when people wait too long to set it up or if they enter it wrong.

Comment: If desired, there could be two types of badges "All-time Recruits" and "Active Recruits". These would be based off the critera total credit >= 1 and expavg_credit >= 1 respectively. The recruits page could then be toggled for either of these conditions. It would be only slightly more work to create both.

[smoe]

I am very happy with the implementation. Why one would look at the number of individuals recruited instead of the sum of their contribution is a bit beyond me, but either way, it is much appreciated.

[TheAspens]

I think the answer to your question is that there is value in recruiting people to the cause even if they only have a little to give and there is value in recruiting fewer people but who have a lot to give. Both I think are important metrics. Valuing the individual and growing the community is important. Recruiting raw computing power is important. I honestly cannot say which is more important. At WCG we take a bias towards growing the community as the first objective and believing that within that grown community we will add power users who bring a lot of computing power. For that reason I lean toward focusing on the community growth as the metric. However, I don't know if this perspective is correct or not. In the end - I would be fine with either approach.