Yeah. After experimenting a bit with it - seems that Wiki in Github is a bit "abandoned" place and omissions like lack of auto-linking issues and PRs is a big bummer.
Kamil - would you mind re-creating the issue based on the old issue? I - unfortunately - added all "Apache Committers" to it so we cannot re-open it. But I have another question here: 1) Should we remove https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+2.0+-+Planning completely? 2) More than that - should we archive and move everything else from CWiki to Github Issues? I think it will be very confusing (especially for new contributors) if we keep some information in CWiki but also start using Github Issues for similar purpose. So I would be for archiving all content in the CWiki and moving it all to Issues. I took a look at the kind of documents we have in CWiki and we have a LOT of information there that is outdated or could live elsewhere. Here are my proposals: * Airflow 2.0 planing - we could completely move it to "Airflow 2.0 Release" issue * AIPs - we could keep all the completed AIP-s there (And keep the "proposed" ones for the future) but we could move all the "active" AIPs to Github Issues and add all the new AIPs there. * Airflow Links - we can abandon it (It's already abandoned in fact - last update May 2017) * Airflow Release Planning - we could review it and turn it into a "meta" issue - it has a lot fo information about pre-1.10 releases which we can remove (And we will have to redefine it after we agree release schedule and versioning for 2.* series) * Building Docs - is outdated * Releasing Airflow - I think we can move it to Airflow's source code in "dev" folder (like I did for the Backport Packages) * Announcements -> that one we might do on "airflow.apache.org" site as a Blog post ? * API conventions - outdated * Committers/Commiter's Guide -> we could have it in the "CONTRIBUTING.rst" documentation of Airflow (some of the information there is not valid anyway and CONTRIBUTING documentation is much more updated) * Common Pitfalls -> I think that one belongs to the documentation of Airflow not to Wiki and we could select/move some still valid information from there to the documentation * Community Gudelines, contributor's Guide -> this all in CONTRIBUTING.rst * First time contributor's workshop -> this can be moved to a "apache.airflow.org" as a Blog Post. * File lists - > those files can be all added to the airflow repository in "resources" folder or smth. * Meeting notes - Those could be added to relevant issues in GitHub. We could have "meta" issues for "special interest groups" and add meeting notes there. * Meetups -> already part of airflow.apache.org * Product requirements, Roadmap Airflow 2.0 -> this all could be moved to "meta" issues * Roles -> should be added to CONTRIBUTING.rst * Scheduler Basics - > should be part of Airflow Documentation * Season of Docs 2019 -> we can archive it. We could also use Github Wiki to only have "Index" of all important issues that are "permanent" - Airflow 2.0 roadmap, Special interest groups, AIPs, Let me know what you think? J. On Sun, Aug 2, 2020 at 12:31 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > > I agree with Tomek and feel Github issues ("meta"-issue) is a better place > than Github Wiki. > > On Sun, Aug 2, 2020 at 11:26 AM Tomasz Urbaszek <turbas...@apache.org> > wrote: > > > I see the advantage of having no comment in wiki but in the longer > > run, I think this will create confusion. Where should I discuss a > > particular thing? On devlist? Slack? In issue? How should a new > > contributor know this? > > > > After giving some thought to that I'm leaning towards the meta-issue: > > - they are clear (no need to go to wiki) > > - give possibilit to link other issues/PRs that shows their content on > > hover > > - this is great advantage as we can see how our work is interconnected > > - having an issue make it explicit to where contributors should leave > > their comments > > > > No matter what we decide, we should thrive to limit the places where > > information is available. > > > > Bests, > > Tomek > > > > > > On Sun, Aug 2, 2020 at 12:00 PM Jarek Potiuk <jarek.pot...@polidea.com> > > wrote: > > > > > > Question. Should we move over Airflow 2.0 Status and other "permanent" > > > information to Github Wiki? See here for example: > > > https://github.com/apache/airflow/wiki/Airflow-2.0 > > > > > > The discussion originated by Kamil creating an issue for Airflow 2.0 - > > > which was essentially overriding the page we had in > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+2.0+-+Planning > > > and adding more "status" information in > > > https://github.com/apache/airflow/issues/10085. This was more of a > > > "meta" issue as it has a lot of unrelated issues / projects mentioned > > > - the only common thing for those was that it was "Airflow 2.0". But > > > we already have "Milestone 2.0" and CWIKI page. > > > > > > My proposal was that since we have 2.0 Milestone already we should use > > > this one to mark issues for 2.0 and in order to keep > > > Roadmap/Plans/Status we can use Github's Wiki instead. IMHO it is much > > > better as it does not allow comments - which is good IMHO. For this > > > jind of "permanent" pages, comments and discussion should happen for > > > the individual issues not for the page itself (especially when you do > > > not have in-line comments). > > > > > > And this page should always be "current" - with the old roadmap in > > > CWIKI and the issue 10085 when you add comments, you quickly lose > > > track whether the comments are more important than the overview, and > > > how accurate the "overview" is. When you just edit the wiki - you > > > always do it deliberately - because you want to update status rather > > > than make a comment or discuss, > > > > > > So I created this as copy of the issue: > > > https://github.com/apache/airflow/wiki/Airflow-2.0 so that we can > > > compare it - can you please compare it with > > > https://github.com/apache/airflow/issues/10085 and voice your opinion > > > what's better? > > > > > > I think it's also a great opportunity to archive a lot of the old and > > > not up-to-date from the old Wiki and migrate it to GitHub. We could > > > move AIPs to Github issues (as needed) - AIPS are fine for > > > discussion/issues/comments, but when they got implemented we could > > > move it over to wiki as "Implemented" status for history. > > > > > > Let me know what you think. > > > > > > BTW. PLEASE do NOT comment on that #10085 issue (it's now locked and > > > closed). I accidentally (shame on me) notified all Apache Committers. > > > Happened twice today (also for someone else) so I opened a ticket to > > > Infra to restrict that (If only possible) because it's all too easy to > > > notify everyone @Apache). If you comment there 3K+ people get > > > notified. > > > > > > But feel free to upvote the infra ticket: > > > https://issues.apache.org/jira/browse/INFRA-20623 > > > > > > > > > J. > > > > > > > > > > > > -- > > > Jarek Potiuk > > > Polidea | Principal Software Engineer > > > > > > M: +48 660 796 129 > > -- Jarek Potiuk Polidea | Principal Software Engineer M: +48 660 796 129
