Update pull_request_template.md

[jessicaschilling]

First pass at an improved PR template for awesome-ipfs. @andrew -- we'll need to change the pre-submit checklist based on what you figure out surrounding the mechanisms of making a PR easier to make. In the meantime, please take a look at the remaining questions to see if they're useful for getting a bead on collabs.

cc @momack2 @autonome @renrutnnej

[jennwrites]

I wonder if we should include a link to the confirm review of the project code of conduct as well as the content policy? Thoughts?

[RubenKelevra]

The first section should be no "checklist", but just a point list.

A checklist entry should be to confirm that the changes only cover "one" item of the list above, and ask the user to write which one... or similar.

The advantage of a checklist is that you can see the "progress" of a PR in terms of checklist completion in the PR overview as bar.

When we expect the user not to check everything, this bar is not useful.

[jessicaschilling]

Hi @RubenKelevra -- you raise a good point about checklists being used for off-label purposes. It isn't ideal to use GitHub checklists for "check one" purposes, because of the impact on a progress bar, but I'm suggesting that the alternatives would have a more negative impact on user experience:

• Using a mechanism like "delete all the things in this list that don't apply" is more difficult for the user than just checking one or several boxes, and increases the chance that the user just won't bother
• Forcing the user off-site to an external mechanism designed for this sort of question-and-answer (a Google survey, or whatnot) disrupts entirely the experience of making the PR, and increases the chance that the user won't bother, or will abandon the PR entirely

For this reason, proposing that we keep using the "check one" boxes, as we have previously in this PR template, but revisit later if we find it's a blocker.

[RubenKelevra]

True, user experience is key here. Good idea to postpone this after the PR has been completed.

[RubenKelevra]

This is somewhat related and might block this PR until decided. I really like to clean up the categories a bit to make it easier for the users to understand the content (e.g. the difference between a commercial service and an open source project you can host yourself).

Maybe we can discuss first the cleanup of the categories, to directly incorporate the good questions for the maintainers to select the proper category.

I volunteer to review and resort the content, and create a PR for RFC afterwards.

#323 (comment)

[jessicaschilling]

@RubenKelevra -- thanks for your work on #323. I think we can approach this iteratively, and update the PR template again later if/as needed when the categorization logic changes.

@andrew, do you have write access to this repo? I think we could merge this version now, and amend it again later once you've taken a closer look at the merge process and how we might be able to make that easier. Thoughts? If you're OK with that, do you mind merging?

[RubenKelevra]

Looks good to me

[andrew]

Suggested to change formatting of the hints to html comments so they disappear from the PR body once it's been submitted

[jessicaschilling]

@andrew - good idea on the comment lines. I've made the changes -- can you please give another look and merge if you're cool with it?

[andrew]

✨