getmoto
First draft at description of feature requests vs bugs.
I should also note: if we merge something like this, I will close all existing "enhancements" issues with a message pointing at this guide.
Coverage decreased (-0.0002%) to 93.095% when pulling 0c071390d46032556d5f2b912b62ec2d2af5f355 on issue-triage into 9acdc59aa4ec54e2b995a4793503513e0b0dc055 on master.
Coverage decreased (-0.0002%) to 93.095% when pulling 0c071390d46032556d5f2b912b62ec2d2af5f355 on issue-triage into 9acdc59aa4ec54e2b995a4793503513e0b0dc055 on master.
I think that we should mention that in general, people will submit pull-requests for features when they need a feature for their internal tests. One should not assume that the community will contribute the feature.
We encourage users to submit PRs to implement the features in moto whenever a feature is missing or incomplete.
I like the direction this could take moto, even if it could be a bit confusing for new users. I'd argue that we do need to use labels a bit more to differentiate between:
- Feature requests
- Closed (fixed) issues
Does it also make sense to start using labels to differentiate between implementing:
- new services
- new methods
- missing behaviour from an existing method?
Personally, when I submit a PR, I don't always look for the feature that I expect to be the most popular/has the most upvotes. If I only have a few hours to spend on it, I'll look for something that is easy to pick up. Having labels to differentiate the type of issue (and by extension, the work involved) would be very useful.
I guess we could also expand the ## Is there a missing feature?-paragraph to say: Before creating an issue, please search for closed issues, labeled as x/y/z. Makes it hopefully clear for people.
