Earlier quoted context omitted.
I totally get where you're coming from. An extra file in your repository is quite the burden. This template file is the straw that broke the camels back. It should be removed. But why stop there? Let's also remove the README.md from the repo. It can also have it's own independent revision history. Maybe they should also add a feature for managing the LICENSE file for you. /sarcasm
Except that CONTRIBUTING.md and README.md and LICENSE are all typical files found in a repo that are independent of GitHub. If I push this repo to bitbucket or gitlab, the same stuff is just as important. But `issue_template.md` and `pull_request_template.md` is only dependent on github and is clutter in the repo. Sure if gitlab or bitbucket have these features and use those names, cool it translates to those service…
Issue and Pull Request templates
141–143 of 143 posts
Re: Issue and Pull Request templates
#142Now I actually start to worry. Did anybody here ever have the problem of making people happy with a software project? The usual complain goes like this "You need to do X because I want to be able to do Y." In the complainers mind there is the untested idea that having X will enable him to do Y which solves his unspoken problem Z that he isn't even aware off. The thing is, at this time you don't know Z. You don't know…
If one or more of the variables were GitHub, or issue templates, then:
Don't be concerned. The user community listed grievances with some missing functionality. GitHub listened and implemented some. In this case without changing functionality for people who didn't want this. (So the person who likes the URL method can stick with that.)
Good on GitHub implementing something to help their users. Isn't that what we want? Or do you want then to ignore their community?
Re: Issue and Pull Request templates
#143Now I actually start to worry. Did anybody here ever have the problem of making people happy with a software project? The usual complain goes like this "You need to do X because I want to be able to do Y." In the complainers mind there is the untested idea that having X will enable him to do Y which solves his unspoken problem Z that he isn't even aware off. The thing is, at this time you don't know Z. You don't know…
I'm confused, probably because of too much variable usage in your comment. If one or more of the variables were GitHub, or issue templates, then: Don't be concerned. The user community listed grievances with some missing functionality. GitHub listened and implemented some. In this case without changing functionality for people who didn't want this. (So the person who likes the URL method can stick with that.) Good on…
X = proposed solution by users, Y = guessed problem by users, Z = actual problem nobody knows about yet.
The proposed solution is only maybe a solution to the proposed problem, probably not. Because users won't go and try things out and then come to you and tell you what they found out. They have a feeling in their stomach and they tell you about it. The same goes for the problem they tell you about. It's maybe not their real problem but a symptom of another problem. You need to go and solve the actual problem.
Example: Patient (=user) goes to doctor (=github) and says "I have a headache (=Y), please give me some pills against headaches (=X)". Well, headaches can be because of lack of sleep, lack of water, too many worries, an infection, or maybe even cancer. Now the doctor's job is to figure out which of the actual problems it is. He talks to the user, does some analysis and figures out the actual problem is lack of water (=Z!!!). He tells the patient to drink more water (solving Z, Y is indirectly solved, and no word about X). Patient goes home, drinks more, is happy, doesn't come back to the doctor.