I think it describes very well what we discussed so far. I have two points
to add:
1) Using Milestone:
I prefer to keep milestones to only mark stuff for global releases of
Airflow and nothing else. If we use Milestones for SIG groups this will
become unmanageable (and I know Milestones are used by the release
management scripts to verify if everything marked for release is already
merged).
2) CWiki vs. Github Wiki and Index of "Currently running Airflow
initiatives"
Another thing that I wanted to add is whether we use both wikis (or one
only) after cleanup I proposed.
I think CWiki is better for design docs/discussions etc. - it has diagram
support built-in and a few other features that make it easier to have
better "design" discussion. Github Wiki is very poor.
I agree that Github issues are great for most of the stuff. But I think we
could use Github Wiki to keep index with links to the issues + one sentence
of explanation for those more "permanent" and long-running "meta"
issues.I'd call it "Currently running Airflow initiatives":
What I can see there currently is:
* Airflow 2.0 Progress
* Backport Release 2nd wave
* Quarantine Issues (master, v1-10-test, v1-10-stable)
* Refactors and cleanups
* Pylint
* MyPy
* ...
* SIG Groups
* link to meta-issue for each SIG Group
This would be a great point for newcomers to have a look of what's going on
currently in Airflow without having to look at 500 issues. It might be
obvious for more seasoned committers that those initiatives are in progress
but you would not know that before you go into details of individual "meta"
issues (and you'd have to know that there are those meta issues in the
first place). i think it's much more discoverable if we just have one page
in Github Wiki with those.
WDYT?
J.
