-
-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved the description of the issue templates #554
Conversation
Codecov Report
@@ Coverage Diff @@
## master #554 +/- ##
=======================================
Coverage 68.19% 68.19%
=======================================
Files 172 172
Lines 10573 10573
=======================================
Hits 7210 7210
Misses 3363 3363 Continue to review full report at Codecov.
|
Benchmark for 5dc8ea2Click to view benchmark
|
I think reporting of incorrect, deficient or missing JS features should all go under Bugs. The functionality of boa is to follow the latest ECMAScript, and any deviation is a bug. It is not up to the end user (reporter) to know if the implementation is incorrect, deficient or completely missing from Boa implementation. (ofc, if the reporter is aware of these details, it is good that they put them in the additional notes in the issue report) |
I think this is good especially since we will hopefully have test262 up and running soon and so, therefore, will have a good list of features which need implementing. |
Would anything that doesn't conform with the test262 be an unimplemented feature then? What will be a bug then? |
If something like |
How would someone using boa and reporting a bug know if it is unimplemented or not working as expected? For example, I'm testing:
And boa outputs me |
Benchmark for b5fe179Click to view benchmark
|
Pretty much, I suspect we will have a significant amount of areas which will need addressing.
I suppose if they aren't involved with the development of the boa project then making that distinction falls to us to re-classify if required. |
And also the example of granularity:
|
The project has started pretty recently, at least with the current level of development speed. For example 8 months ago, most of the standard was not implemented. If you want something in the standard to be prioritized for implementation, then it's a feature request. If we add a bug for each unimplemented feature, then We can't even run test262, so most things are feature requests IMHO. Once we have that running, and we iron out bugs in our current implementation, we will have a list of non-implemented things, and there we can more clearly see the difference between a new feature or a bug. We don't always implement the full thing when implementing a new feature, and we leave some things unimplemented. Your own #543 PR is an example of this. We have the unimplemented second parameter in
I think that if the If we have an implementation for one parameter, but in an edge case, it doesn't work as expected, then it's a bug. It's ok, until we don't have the test262 ready, the creator of the issue doesn't have to know if it's a bug or a feature. We can tag it later and add a comment explaining it, but if the creator of the issue has some experience with the project, they can maybe know if it's a new feature or a bug. |
This PR changes the description of the feature request and custom issue templates.
It should avoid issues like #552, where a new ECMAScript feature is requested, but we have no links to the spec or no description of the feature, with no code example that would be affected.