Comments (6)
@nicoddemus, @Zac-HD, @bluetech, @RonnyPfannschmidt, @flub - would be nice if you could give some feedback if there is anything catastrophically wrong / missing. I want to start with this then later in the week. This is something that can be done in smaller chunks after the sprint, so not really time critical, but would be nice if we can get consensus about this while everybody is in sprint mode and also ideally already get started with this.
from pytest.
This sounds good to me! I'd add:
- close issues which could feasibly be implemented as plugins outside this repo
- automatically close feature requests which are more than one year old.
- I think this is a good reason to keep separate
feature
andenhancement
labels, or some other way to distinguish "improving an existing feature" vs "adding a new feature".
- I think this is a good reason to keep separate
- a docs page explaining the labels and criteria to close an issue would be helpful for both maintainers and contributors (both people opening issues, and people opening PRs)
Random other thoughts:
- I'm pretty dubious about whether we have any "good first issue"s; they tend to be things that looked easy but often turn into a classic yak-shaving adventure which is not a good experience for new OSS contributors.
- It would be nice if the
bug
issues were prioritized for fixing, but 🤷 if the volunteers don't want to, I'm not telling them to.
from pytest.
sounds reasonable. I think labelling features is probably better than closing as they can more easily be referenced as already existing. Otherwise it is harder to remove duplicates.
from pytest.
or just closing is probably more useful at the size of the issue tracker...
I also can't help but note that this issue adds one more open issue :P
from pytest.
I also can't help but note that this issue adds one more open issue :P
:D - oh trust me: I'll be closing enough to balance that out during the sprint.
from pytest.
Ok, here is the refined plan (if you want to just check the diff: obestwalter/pytest-sprint-2024@68f06c7)
We have more than 800 open issues, quite a few of them very old and with no proper follow-up and quite a few might be good first issues, if provided with a bit more context.
We had a small discussion already with @The-Compiler and @webknjaz - the rough plan is going through issues with these things in mind:
- If the issue is really old and it is not quick/easily to reproduce it, ask for follow-up and mark with needs: information - we already have automation that those are auto-closed then after a month
- if it is easy to reproduce: reproduce it, add a comment that verifies the reproduction and update the original issue comment with that info and a link to the reproducing comment, so that it is clear right away that this might be an old issue but it is still valid
- If an issue is obviously already solved or invalid, close it right away with the proper explanation
- If something is not yet labelled properly, add the proper label (D'UH!)
- If something looks like a good first issue, add the label - there are doubts that there are any good first issues, but it's worth a try. This might help:
- Add a bit more context for people to get started, if more experienced devs can give some pointers already, this might turn it into a doable task
- if it is a bug, and it does not have a reproducer already: write one marked as XFAIL
- Review issues labelled
help wanted
as basically we want help with everything. We should the ones that are suitable as good first issue and simply remove the label in the other issues. - Close issues which could feasibly be implemented as plugins outside this repo
- (Maybe) prioritize the bugs (volunteers can fix or not fix wahtever they want, but maybe some pick higher prio bugs if they know they would have a higher impact?)
Other things to do
- Add automation to close feature requests which are more than one year old (this will likely be controversial, but the thinking here is, that if it is a good idea it will come up again later, or someone will dig it out of the closed issues - more ruthlessly closing feature requests that are not being picked up is the better alternative than clogging the backlog with potentially stale ideas).
- Improve the labels:
- rename
type:docs
totopic:docs
as this fits better there - rename
type:infrastructure
totopic:infrastructure
same reason as above - rename
type:feature-branch
totype:feature
- we do not really have feature-branches as such anymore
- rename
- Document the labels:
- e.g. clarify the difference between
type:enhancements
(improving and existing feature) andtype:feature
adding a completely new feature
- e.g. clarify the difference between
- Document how we (want to) handle issues and PRs (mainly what are the criteria for closing) with the aim of being helpful for contributors and people opening issues
from pytest.
Related Issues (20)
- MockAwareDocTestFinder._find is stale
- Pytest documentation website issue: Python code example blocks not rendering properly in pytest documentation HOT 3
- pytest 8.2.2 fails assertion HOT 1
- pytest approx wrong formatting return - printing all values as wrong.
- pytest 8.2.0 calls `@property`s during unittest collection HOT 11
- Attempting to `dill` a function defined in a `doctest` run with `pytest` causes a `TypeError: cannot pickle 'EncodedFile' object`. HOT 6
- pytest.warns() as a context manager is difficult to check multiple warnings HOT 2
- Module Scoped Fixture Invoked Multiple Times with Indirect Parameterized Tests
- Bring back link checks HOT 1
- imports of distutils pick up wrong parent module HOT 7
- [Python 3.13.0b2] `test_pdb_used_outside_test` and `test_pdb_used_in_generate_tests` are failing with Python 3.13 HOT 1
- Refactor underlying data structure of assertions AST from string to something more flexible
- `ExceptionGroup` ergonomics in `pytest.param(..., marks=xfail(raises=...))`
- `pytest.raises` with invalid regex in match kwarg fails with internal `re.error` HOT 1
- pytest consistently raises ImportError HOT 1
- @RonnyPfannschmidt this results in the `|release|` RST substitution having the value of `8.2` which might have a weird perception in changelog draft titles: https://docs.pytest.org/en/8.2.x/changelog.html#to-be-included-in-vrelease-if-present / https://docs.pytest.org/en/latest/changelog.html#to-be-included-in-vrelease-if-present. HOT 1
- `xfail`ed tests are reported as `skipped` on `TestReport` instead of `passed`
- Support venv detection on Windows with mingw Python HOT 5
- pytest ignores `-P` (avoid prepend) argument provided to Python HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pytest.