Open iandunn opened 2 years ago
One big issue is spam/fake company pledges, as those eats credibility of valid pledges. There are currently 163 pledging companies, from which, unfortunately, many are either spam or otherwise highly suspicious and that can be seen easily.
What if company pledges should be manually approved? Automated approval requests could be sent only after the company has the first contributor. That would most probably drastically reduce the issue when combined with #168 and #166. The number of company pledges do not seem that high, that manual approval process would create too much work.
🤔 I like that idea, but IIRC Andrea's vision for the program was intended to allow "optimistic" pledges, so having a prior contribution wouldn't necessarily be required. It may be worth reconsidering that, though, given the problems we're having. Do you have any thoughts @angelasjin?
Regardless, moderation could still be helpful in clearing up confusion, though, like someone reaching out to explain that having a plugin in the repo isn't the same as contributing to the Plugin Review Team.
Since we haven't done any clean up of spam pledges at all, I'm inclined to let companies be auto-approved, as long as the plans for regular clean ups and greater connection between contributor teams and pledged contributors come to fruition. If we still are getting an overwhelming amount of spam/fake pledges, then I would reconsider manual approval.
Anything we can do to help clear up confusion and increase communication, I am a big fan of for sure.
I think Andrea's optimistic vision is exactly right and should set the tone for how we improve things. We're asking for volunteers, so we should start by assuming good intent rather than suspected spam.
There are ways we can structure the process so spam and unrealistic submissions will naturally atrophy. For example: accept any and all pledges, but start by flagging them as oboarding / new recruits / apprentice or similar, and only making them privately visible to the pledged team reps. Once they've met some criteria (attending a meeting + completing an onboarding checklist + making a contribution?) they graduate to visible. If they haven't contributed in a long time, they become "past contributors" and are listed separately or not at all.
And on the other side: make the list of companies and pledges only show those that are currently active. Rather than think in terms of nuking spam, use it as an outreach opportunity: send an email to say we noticed [some of] your contributors haven't been active recently; the team has some exciting new projects coming up, so contact xyz to find out how you can help. Give them the benefit of the doubt: it's possible the companies don't know their employees have dropped out of contact, or that there's been some mismatch of expectations.
I think that's a really good idea! I just published a proposal on make/Project, do you mind posting it over there so we can discuss it more broadly?
This is a tracking issue for milestones 6, 8, and 9. It's combined here to make it easy to see the bigger picture, since each milestone is dependent on the previous one.
See Andrea's post and the proposal for background.
Planning
Manual spam/dormant clean up
Start tracking non-code contributions
Automatically add various “props” for each non-code team to Profiles activity streams. These will be needed later on, so we can automatically determine if a pledge is dormant or not. We already track plenty of code contributions, but not nearly enough non-code ones.
See https://github.com/WordPress/five-for-the-future/milestone/8 for detailed issues
#props
channel (related to https://github.com/WordPress/five-for-the-future/issues/174)Automatically notify inactive contributors/companies
See https://github.com/WordPress/five-for-the-future/milestone/9 for detailed issues
Potential Iteration to automatically deactivate inactive contributors/companies
If the manual reminders aren't effective enough (and I suspect they won't be), then we could add some additional automation to deactivate pledges at the 6 month mark.
See https://github.com/WordPress/five-for-the-future/milestone/6 for detailed issues