[DEPRECATED - used to be release Airflow 2.0 but we moved it to #....

[mik-laj]

This ticket has been moved to: #10152

[potiuk]

+1

[potiuk]

I love to switch to Github issues for planning.

However I think we should organise it slightly differently, Github already has all the levels of details that we need and trying to squeeze it all into "Umbrella" issue is not the best use of those.

I have two proposals:

1. I think it's much better if we use "Projects" features for each of the "sub-tasks" leading to 2.0 - for example I added my https://github.com/apache/airflow/projects/3 to complete the "Production Docker Image". It gives much better feeling of the status and progress.

2. I believe what is described in this issue as a description should be in 2.0.0 Milestone description and status should not be an issue, but more of a Wiki page as it will get continually updated, I think it might be a better idea to enable Wiki part of the GitHub and keep all the 2.0 related stuff in it (including the roadmap and status). It will be much better to keep it linked to the Github Issues and Projects, and at the same time we can eventually gradually move all the relevant stuff from the confluence - similarly as we did with JIRA issues.

@mik-laj @kaxil @apache/airflow-committers WDYT?

[mik-laj]

I agree that we can think about using the projects, but the umbrella ticket is still helpfull. This will allow new contributors to become more familiar with the plan. I would like this ticket to be the place a new contributor should start off if they want to work on Airflow 2.0.

If we want to organize our project as a kanban, we will have several columns such as Blocked, TODO, WIP, Review in progress, Review approved, Done. This allows you to easily follow the progress as you can see the cards move to the right. However, these cards are chaotic for someone who is unfamiliar with the project. They don't know why something needs to be done and he doesn't know the full context.

I would like to point out that even we use a similar document during our work in various projects at Polidea, but we have it in the form of a spreadsheet. We tried to use Github Issues, the Github project, but in the end the spreadsheet turns out to be the most helpful. I also have a similar spreadsheet for organizing work on REST API and I usually look at it if I want to see what is the progress of work. On the other hand, I am very happy to use Github projects, but in other cases. I also have many more cards there than in the spreadsheet.

We can move to the wiki, but I don't see any benefit over using the Github Issues. On the other hand, using Github Issue will allow you to reach a wider audience more easily.

[potiuk]

I think now we have information spread in a few places - roadmap and AIP in Cwiki, "umbrella" issues which are mixed with "normal" issues (and you do not know which ones are which until you read them). I think it's not at all easy to contributors to know what's going on. On the other hand if we have roadmap in one place in Github Wiki, we have the benefit of it being close to issues and PRs (and discoverable in a similar way) and we can add easy references to PRs and issues via # and we still can use markdown etc. .The main different is that isues are rather efemeral and they should be closed and "removed" from the immediate results as soon as they are done, where Wiki page is more permanent.

I think such an umbrella issue is "artificially" trying to recreate what Wiki + Projects were meant to. Wiki + project seems like a perfect replacement for such "umbrella" issues - in Wiki you describe Why's and link to milestone and pr, In Projects you keep information on which issues you implement. And you have back reference from issues to project and to milestone. And you can track the progress of those.

[potiuk]

I think it would be great to simply try and see it before we decide - I created #10110 to enable it experimentally and we can see if we like it or not.

[mik-laj]

I have no problem with giving the ticket a label that will allow you to easily distinguish it from other tickets. However, this still allows us to keep all the information in one place without having to use another tool.

The wiki has one major limitation - it has no comments. you cannot comment on entries, which is often helpful to request status updates or more information.

[potiuk]

I think that's a deliberate decision for Wiki not to have comments (and it's a good one). Comments can be kept in the issues but they make it messy for "permanent pages" - you can see that in the CWiki (where a lot of stuff happens in comments and it is often not reflected in the "permanent" state of the page - or even in this one - we already have more comments than the issue description and this is hardly useful for anyone to read them in the context of "Airflow 2.0" - you do not know if everything in the comments is already reflected in the description, which part is relevant and which comments are important. So you don't bother eventually.

Wiki makes it nice that you have to edit it and once you do it, your change becomes the "current status". while you can still keep the history if you want. It makes it ideal for the kind of "status" and "roadmap" pages.

I'd say - let's try it and see - we can always go back it's a low-cost decision and easy to go back if we do not like it.

[potiuk]

I copied it there: https://github.com/apache/airflow/wiki/Airflow-2.0

I honestly think it's much better than "umbrella" issues or "kind:meta" label. WDYT @apache/airflow-committers ?

[HyukjinKwon]

@potiuk, fyi apache/apache-committers notifies all committers in Apache projects.

[potiuk]

Really sorry :(. I changed to intended Airflow-committers I hope everyone is not subscribed now. if they are then I guess we will need to close that one.

[turbaszek]

Ok, I'm getting confused as there's one more place to discuss Airflow 2.0. How this corresponds to cwiki?
https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+2.0+-+Planning