Filling up PULL_REQUEST_TEMPLATE.md demands too much!

[Bost]

I'm realizing I invested much more time in the paper work than in the actual code change + pull request. Please get rid of it. Time is the luxury none of us have! Thanks.

[vspinu]

I second this in part. At least one can say "Check all that apply and ignore the rest" so that contributors won't feel obliged to explain un-marked boxes.

The box "The new code is not generating bytecode or M-x checkdoc warnings" should be updated with instructions how to do that (make test-bytecomp and make test-checks; or all at once make test-all). One big hurdle is that depending on the version of emacs in use at least one of the test bundles won't pass locally. I have 4 version of emacs on my machine and none passes all tests due to idiotic system or emacs issues.

And BTW, CIDER's template is one big pain in the ass as well.

[Malabarba]

I feel like we can't remove it completely. Just like contributors don't like spending time checking those boxes, we don't have time to manually validate and explain those items ourselves when people submit PRs.

Still, I've opened a PR trying to make the template more lenient and removing the biggest pain points.

[bbatsov]

And BTW, CIDER's template is one big pain in the ass as well.

Because you're not the one who has to waste their time with bad pull requests. I value my time just as much as the time of the contributors. I've listed everything I consider important and I really don't think we'd be gaining anything from removing things from there. It's not like many people actually read this, but I'm grateful to everyone who does.

[bbatsov]

I'm realizing I invested much more time in the paper work than in the actual code change + pull request. Please get rid of it. Time is the luxury none of us have! Thanks.

So you're suggesting wasting my time, right? With or without the template you'd get exactly the same feedback from me and you'd have to do exactly the same work to get something merged. I prefer to put things in writing instead of having to write the same comments and feedback over and over again. I must be a really bad person for valuing my own time.

[tarsius]

I'm realizing I invested much more time in the paper work

This isn't paper work. This is making sure your changes fulfill minimal quality standards. It has to be done by someone in order to make sure obvious mistakes don't make it into the mainline. Either each one of 100 people does it once, or one person does it 100 times. Respect the maintainers of the code you are using by not expecting them to do your work for you because you don't want to "waste time".

[Bost]

I'm realizing I invested much more time in the paper work than in the actual code change + pull request. Please get rid of it. Time is the luxury none of us have! Thanks.

So you're suggesting wasting my time, right?

??? huh ???
How have you come to this conclusion is a mystery to me. Bozidar, SRLY, H-O-W?

Because you're not the one who has to waste their time with bad pull requests.

This reminds me a bit the "Linus doesn't scale" http://linux.sys-con.com/node/32722

I highly doubt anyone here intentionally sends you bad or sloppy PRs.
The key is to make a difference between "I waste my time on ..." and "I have to waste my time on ...".
It pays off big times to make the PR integration process as smooth as possible. Automation and/or delegation is the key.

[vspinu]

And BTW, CIDER's template is one big pain in the ass as well.

I was actually referring to the CIDER's issue template here. Sorry for the confusion.

I've listed everything I consider important and I really don't think we'd be gaining anything from removing things from there.

I think it's more about reformulating the template by keeping the same amount of details. I bet you could reduce CIDER's issue template 5 fold without asking less.

For instance

• The whole version part could be replaced by simple "Paste here the output of cider-session-info.", where cider-session-info could report all those versions and much more (last middleware error, number and type of connections, loaded middleware, important config parameters etc).
• The "expected/actual/step-to-reproduce" is too rigid of a template. Many bugs cannot be structured that way and even if they could stating all three in one coherent paragraph is usually a much better idea. Simple "If applicable, please state the (1) expected and (2) actual behavior, and (3) steps to reproduce." would be just as informative but would leave users with the ability to structure the report as they want.
• The preamble and "This is extremely important!" parts could be removed completely IMO. Those are not that useful and are rather distracting.

Because you're not the one who has to waste their time with bad pull requests.

I think this one really got in wrong direction. We are all here in the same boat. A lot of us spend huge amount of time working on these projects and it's in everyone's interest to streamline the PR and issues reporting process. So, wasting time on who wastes whose time is a wasteful waste ;)