What should a feature request include?

What should a feature request include?

Writing feature requests and bug reports that get results

1. Briefly summarize the request. Ideally this should be no more than a few words.
2. Describe the current situation.
3. Describe the desired outcome.
4. Describe the benefits of the change.
5. Describe the negative effects of the change.

Is it a bug or a feature request?

A bug is a discrepancy between how code is actually working and how our code was intended to work. A feature request requires new code to satisfy a case that can’t be handled by the current codebase. This kind of thought-process always leads us to the more general question of how software like DoneDone should be used.

How could a feature be confused with a bug?

A bug is a failure to conform to reasonable expectations based on requirements and norms. A feature is a unit of functionality that is requested as a requirement or change request.

Is a missing feature a bug?

“That’s not a bug, that’s a feature!” is a common catchphrase. When 19th-century inventors and engineers started using bug as a synonym for defect, they were talking about mechanical malfunctions, and mechanical malfunctions were always bad.

Can a bug be a feature?

A feature is a functionality intended to be useful to the user. A bug is a behavior, usually the result of an error or sloppy programming, that gets in the way of the features. Antifeatures, unlike features, are not useful from the standpoint of the software user.

What do you do when a client asks for a specific feature that you don’t have?

Feature requests that you are not working on

1. Find their real need. Before replying “No” immediately, pause for a moment and think from your customer’s perspective.
2. Offer workarounds. As we talked about in politely rejecting customer requests, there’s some kind of “yes” most of the time.
3. Give an honest explanation.

Why are bugs and feature requests handled differently?

So, depending if your work success as a software developer is based on certain factors, bugs and feature request might be handled differently. For example: If your work success is based on fixing any bug that arises, new feature requests will take longer to be developed.

How to determine the importance of a bug?

One way to evaluate the importance of a bug fix or feature request is by looking at the value your implementation is causing. A bug causing a dead footer link might not be as valuable as a bug affecting the user’s payment. Many teams already proceed with that step by asking “how important a bug fix or new features is”.

Which is an example of how to prioritize bugs?

For example: If your work success is based on fixing any bug that arises, new feature requests will take longer to be developed. However, if your work success is based on developing new features for your product, bugs won’t be fixed as fast. So, how do we prioritize bugs?

What’s the best way to respond to a bug?

Andrew recommends saying “Let me check with the team and get back to you with more information.” over “I’ve reported that bug to the team so we can get it fixed up.” Promising to fix a bug or implement what seems like a basic feature risks frustrating the customer. The “bug” may not be a bug.