github/opensourcefriday

Suggested improvements to user page

Closed this issue · 3 comments

Building off of #40, a few more things to build out the user page:

  • How do people sign up for emails? Do we automatically add them to Mailchimp when they sign in, or should they manually opt in on the dashboard? (Side note: I'm not totally convinced we should still do emails, let's chat when you're back @MikeMcQuaid)

  • On the homepage, "Sign up with GitHub" should be a front and center button in at least two places:

screen shot 2017-04-26 at 1 20 38 pm

and

screen shot 2017-04-26 at 1 21 03 pm

For the maintainer page, I'd similarly put it: 1) on the hero and 2) below the Get ready for Open Source Friday heading/subtext.

Oh another question. The user page shows @prs_count, but I'm not sure that's the right metric.

Andrew's original vision (#2) was to make this "not tied to pull requests", which I strongly agree with.

Can we count a broader set of activity here? e.g.:

  • Commits
  • Reviewing PRs
  • Commenting on an issue or PR
  • Closing issues
  • Merging PRs

How do people sign up for emails? Do we automatically add them to Mailchimp when they sign in, or should they manually opt in on the dashboard? (Side note: I'm not totally convinced we should still do emails, let's chat when you're back @MikeMcQuaid)

@nayafia 👍 to chatting more. If we do I'd say allowing them to opt-in but putting it front-and-center when they first sign in your be good. Additionally, I think allowing people to just enter an email address somewhere lower down the page would be good (if not signed in).

On the homepage, "Sign up with GitHub" should be a front and center button in at least two places:

Agreed 👍

Can we count a broader set of activity here?

I'll investigate further but it's going to be a bit more complicated/"expensive" (re: API quota). I think this is linked to the commit access you've mentioned; I don't think someone should be considered to have participating in Open Source Friday from commenting on a random repo they don't have commit access to.

Can we count a broader set of activity here?

I investigated the APIs we provide for these things (i.e. search) and it's not great news, I'm afraid.

  • Commits: we cannot do global, site-wide commit searches based just on username and being public (we may be able to do this if we had users e.g. manually enter the specific repository their commits are on)
  • Reviewing PRs: we can search for PRs reviewed by a certain person but not the date on which that review happened (without an additional API call for each PR to check the date)
  • Commenting on an issue or PR: we can search for issues/PRs reviewed by a certain person but not the date on which that comment happened (without additional API call, as above)
  • Closing issues: we can't do global, site-wide search for issues that were closed by a given user (we may with manual entry, as above)
  • Merging PRs: we can't do global, site-wide search for PRs that were closed by a given user (we may with manual entry, as above). The other approach would be to serve for merge commits which works in the same way.

At least for the contributor workflow: I don't think any of the above are going to be possible in a way that provides a good user experience, scales, and/or produces correct data. I do think the PR is the fundamental unit of work for non-maintainers on an open-source project, though. I don't think that any of the above would be valuable from contributors on any projects I maintain currently or previously.

For the maintainer workflow it's a bit trickier; arguably if we're just looking at their creation of PRs they aren't really being nudged into separate workflows than contributors. Maybe that's OK (I think it may be) but if it isn't then maintainers are likely to know in advance which repositories they are likely to perform Open Source Friday work on and could add them on signup and we can search for some of these other actions (e.g. commits, reviews) in their repositories specifically. Again, this has the potential of scaling problems so we'd probably need to limit the number of repos they can add.

Note this issue will be auto-closed shortly but let's keep talking about things here to keep conversation in one place.