Spec out claim/unclaim/reclaim packages

[chadwhitacre]

---

⚠️ Flight deck for the Claim/unclaim/reclaim packages project moved to #4305. ⚠️

---

Todo

• set up npm syncing—besides just needing to stay in sync, people are going to want to update the email address on file in their package.json and then "immediately" see the new one show up to continue the flow
• make room on the /on/npm/foo/ page for the claiming workflow—move the name to the banner h1, and replace the wombat with the description: Make room for package claiming workflow #4304
• link packages to teams: Stub out Package model #4155
• opt in or out from /on/npm/foo/ pages via email verification
• add payment widget on /on/npm/foo/ pages

---

⚠️ Flight deck for the Claim/unclaim/reclaim packages project moved to #4305. ⚠️

---

[chadwhitacre]

Here are some mockups for claiming packages:

---

---

---

[chadwhitacre]

The list of emails in the second mockup would be the ones we pull from the package.json. Perhaps we can indicate somehow (is bold enough?) that one an email is already added/verified/primary for the participant.

Are we cool with autoapproving all npm packages as projects on Gratipay?

[chadwhitacre]

Once a package is claimed, it behaves almost like a regular project. Claimed package profiles look like a project page. Participants can give to them, and owners can edit them. They can be unclaimed just like projects can be closed. Claimed projects show up on the homepage under the various tabs, and in search results with other projects.

Here are the differences:

• they still live under /npm/foo/
• they retain the npm logo in the profile pic area
• they get a little npm indicator on the homepage and in search results
• assuming autoapproval, there is no approval notice/link (though they can be manually reviewed or rejected, in which case they link out to a GitHub ticket like usual—okay to be manual here)
• their name can't be edited
• the edit danger zone button says "Unclaim Package" vs. "Close Project"
• they can be reclaimed (in which case they are relinked with the same underlying project, not a new one)

[mattbk]

Is an owner created at some point during the claiming process?

[nobodxbodon]

To make sure about the context of the mocks,

1. Is the owner notified by email about such projects to be claimed? Otherwise how do they know of their existence?
2. After step 1, new user needs to sign up manually before they can reach step 2? Could we fast-track it using the email used to notify them in question 1 above?
3. What's the purpose of sending confirmation link in step 2?

[chadwhitacre]

Are we cool with autoapproving all npm packages as projects on Gratipay?

Maybe packages that are older than 90 days? Or that have at least N downloads?

[chadwhitacre]

Without some constraints, it would be trivial to use npm to maliciously bypass our review process.

[nobodxbodon]

Without some constraints, it would be trivial to use npm to maliciously bypass our review process.

Seems the flow is different from our current practice of creating account before creating project. Could we carry out reviewing when user claims project?

[nobodxbodon]

And some more:

• during claiming, beside creating account, user needs to create a team if not it's existed yet?
• user needs to do this N times to claim N projects?
• can owner be transferred already?

[chadwhitacre]

Here's a description of the new flow represented in the mockups:

1. hit /on/npm/react/ as anon, see sign in button
2. sign in
3. hit /on/npm/react/ as auth, see confirmation form
4. click "Send confirmation link"
5. hit /on/npm/react/send-confirmation-link ajax
6. see notification "Check your email"
7. receive email
8. click link
9. hit /on/npm/react/claim
   1. verify the address if unverified
      1. log event
   2. claim package
      1. load previous project if previously claimed else create, link, and load new project
      2. set user as owner of project
      3. log event (inc. owner)
   3. redirect to newly claimed package project page
10. hit /on/npm/react/
11. see npm logo in profile pic area and no approval link
12. hit /on/npm/react/edit/
13. fail to edit name
14. see "Unclaim Package" in danger zone
15. click "Unclaim Package"
16. hit /on/npm/react/unclaim
    1. unclaim package
       1. unset owner
       2. log event (inc. owner)
    2. redirect to newly unclaimed package project page
17. hit /on/npm/react/ as auth, see confirmation form

[mattbk]

during claiming, beside creating account, user needs to create a team if not it's existed yet?

#4297 (comment)

can owner be transferred already?

#3515

[mattbk]

@nobodxbodon, some of your questions are answered on Slack.

[nobodxbodon]

@nobodxbodon, some of your questions are answered on Slack.

@mattbk excuse me I'm not sure where to look at through your link. I also checked the slack channel briefly but I don't see any significant block of discussion about this on slack.

#3515

I guess it's not a blocker, but very likely need to be addressed soon after launching this, especially when there are more multi-developer projects?

during claiming, beside creating account, user needs to create a team if not it's existed yet?

#4297 (comment)

So if a user is leading a 5-dev team for a project, does she claim it first, and then add team member to this project?

[chadwhitacre]

Is an owner created at some point during the claiming process?

Yes, at step (2).

Is the owner notified by email about such projects to be claimed?

No. I think it'll be okay to personally email a few folks (top maintainers, npm itself), but I don't think it's right to blast all of these email addresses we have from the npm database. As @mattbk mentions, we discussed this on slack (though that slackarchive links appear broken? 😞 ).

Otherwise how do they know of their existence?

Folks are going to hear about this from other marketing efforts: via friends on Twitter, or via an ad we take out in Changelog Weekly or on LinkedIn, or via a HackerNews or Reddit post, etc. We could/should identify and test a few channels to see what works.

After step 1, new user needs to sign up manually before they can reach step 2? Could we fast-track it using the email used to notify them in question 1 above?

Even if there was an email, we could only use it to fast-track sign up if we had #1052.

What's the purpose of sending confirmation link in step 2?

If we don't confirm the email ... there's a security risk. I talked about it with Andrew from Libraries.io though I don't recall the details right now.

Seems the flow is different from our current practice of creating account before creating project.

Is it? Step 2 creates the participant account, and step 9.ii.a creates the project.

during claiming, beside creating account, user needs to create a team if not it's existed yet?

No. The team/project is automatically created and linked with the team in step 9.ii.a.

user needs to do this N times to claim N projects?

For this project, yes. I've added "Bulk claim packages" to the todo on Make it easier.

can owner be transferred already?

No. Well, ish: that's a manual db task at this point.

[chadwhitacre]

So if a user is leading a 5-dev team for a project, does she claim it first, and then add team member to this project?

There are no team members yet except for Gratipay. Generalizing twyw is #3433, and it is currently scheduled for the great and glorious future beyond Make it easier. Maybe next year? Year after?

[chadwhitacre]

excuse me I'm not sure where to look at through your link.

Since we are getting bad links from SlackArchive, try this:

https://gratipay.slack.com/archives/gratipay/p1484851952003229

[nobodxbodon]

@whit537 thanks for addressing them again here! Some thoughts about the new flow:

1. hit /on/npm/react/ as anon, see sign in button
2. sign in

the separate 'sign-in' in the message is duplicate in function with the sign-in on top right

3. hit /on/npm/react/ as auth, see confirmation form

Trivial thing: if the user is already signed in, and we find a matching email, we select that as default value?

Related to your comment:

Perhaps we can indicate somehow (is bold enough?) that one an email is already added/verified/primary for the participant.

they can be reclaimed (in which case they are relinked with the same underlying project, not a new one)

How does this work? N owners for one project?

10. hit /on/npm/react/

Are steps below to unclaim a package? Is it in scope of this issue?

11. see npm logo in profile pic area and no approval link
    ...

[chadwhitacre]

the separate 'sign-in' in the message is duplicate in function with the sign-in on top right

Is that bad? We do that fairly often across the site.

if the user is already signed in, and we find a matching email, we select that as default value?

I like it! :-)

How does this work? N owners for one project?

Not sure what you mean. After a project is unclaimed, it has no owner. When it is reclaimed, it has one owner (the reclaimer), who may or may not be the same as the previous owner. Are we on the same page?

Are steps below to unclaim a package? Is it in scope of this issue?

Yes. Yes, because otherwise we end up with a two-year wait as with #3602.

[chadwhitacre]

After a project is unclaimed, it has no owner. When it is reclaimed, it has one owner (the reclaimer), who may or may not be the same as the previous owner. Are we on the same page?

I've added 16.i.a to #4297 (comment) to hopefully make this clearer.

[nobodxbodon]

Is that bad? We do that fairly often across the site.

Just to make sure, through the new link, are we reusing the dropdown to select multiple social profile in the existing button?

Not sure what you mean. After a project is unclaimed, it has no owner. When it is reclaimed, it has one owner (the reclaimer), who may or may not be the same as the previous owner. Are we on the same page?

I asked because I misunderstood your comment below. I thought you meant - after user A claims the project, when user B tries to claim a project again, she will see user A's email being highlighted.

Perhaps we can indicate somehow (is bold enough?) that one an email is already added/verified/primary for the participant.

Yes. Yes, because otherwise we end up with a two-year wait as with #3602.

lol make sense. How about change title to "cliam/unclaim package"?

[chadwhitacre]

are we reusing the dropdown to select multiple social profile in the existing button?

Yes! 💃

How about change title to "cliam/unclaim package"?

Done!

[chadwhitacre]

I think we should try this in a more gitflow style where we maintain a long-lived project branch that we merge to master when the whole thing is done like we did on #4221, vs. the small PRs direct to master and deploy that we did under #3994.

[chadwhitacre]

Though I don't know, if we start with the most deeply nested levels in #4297 (comment) then I believe we're looking at our db layer. I like the pattern of deploying those changes first, and then deploying HTTP API and UI changes in subsequent stages.

[chadwhitacre]

On the other hand, there may be something to be said for building from the outside in a well (!!!), since the outside is the risky part (right?). Stub out data in JSON endpoints, etc. just to get the UI working. Once the UI feels right we start plumbing the depths. Hmm ... 🤔

[nobodxbodon]

since the outside is the risky part (right?). Stub out data in JSON endpoints, etc. just to get the UI working. Once the UI feels right we start plumbing the depths

This sounds more 'agile', and after deciding the endpoints/API based on the settled UI design, UI and backend can work in parallel.

[chadwhitacre]

I talked to an acquaintance here at this coworking space, who was at Credit Karma for 8 years (first hire, managed a team of 100 when he left), and he seems to prefer building from the outside in as well.

[chadwhitacre]

Moving to an integration PR in #4305 ...

[nobodxbodon]

When there are multiple contact emails for one package, indicating there are more than one devs, do we send notification emails out to all of them in case the package is claimed by one of the email?

[kaguillera]

I was wondering the same thing. Which email/person do we allow to claim the package.