Skip to content

Instantly share code, notes, and snippets.

@aoberoi

aoberoi/projects-change-column-with-touch.md

Last active November 2, 2018 19:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aoberoi/bb082dda9e73651ea5f0aa6f8cc30c9b to your computer and use it in GitHub Desktop.
Save aoberoi/bb082dda9e73651ea5f0aa6f8cc30c9b to your computer and use it in GitHub Desktop.
Download ZIP
A couple papercuts I'd like to see addressed in GitHub
Raw
projects-change-column-with-touch.md

What

Create an affordance in the GitHub Projects UI for users on touch-based interfaces to change the column of a card.

Why

Users can already drag and drop new cards into a project using a touch-based interface. But once that card is in a specific column, there's no way to move it to another. This feels maddening, because I'm forced to question whether I am too stupid to see something that should be obvious. I realize that adding drag events would be complicated, because dragging on both the X and Y axes are already bound to panning/scrolling the columns on the board. But, there's a flyout menu ... on each card, that seems like it could accomodate an additional "Move card to..." item, or something like that. This could also benefit users with accessibility needs.

On a personal note, I use GitHub projects to coordinate people on a team. Often times we like to take a walk for coffee and discuss status updates. On those walks, I like to take out my iPad and capture the discussion, and it always frustrates me when I can't directly manipulate the card to move columns on the spot.

Raw
repo-setting-default-new-pr-allow-edits-from-maintainers.md

What

Allow repo owners to change the setting for the default value of the "Allow edits from maintainers" checkbox, when new PRs are created to the given repo.

Why

I beleive that for the vast majority of repos, owners want to do more to help new contributors land their contributions. Sometimes there are just a couple small tweaks needed (e.g. docs updates, small style/syntax issues, etc) in a PR. It's a pain to wait for a back-and-fourth with the contributor, sometimes who are very new and intimidated by contributing in the open, ushering them to just check the checkmark (I've had to send a link to a screenshot or help.github.com pages). An alternative is to land the PR and have a fast follow PR that corrects whatever is missing, but that breaks CI/CD workflows. And to maintainers who prefer squashing all changes into a single commit, something that GitHub embraces already, this alternative would be unacceptable.

Ultimately, this is about onboarding more new contributors into open source repos without making them feel rejection or helplessness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment