I like that idea, Ry. Regards, Kaxil
On Mon, Aug 3, 2020 at 2:32 PM Ry Walker <r...@rywalker.com> wrote: > I'd say the cwiki should provide an overview of the effort, as it does now, > and that we should keep track of the work in a Github project using github > issues. The cwiki should link to that project board as the source of truth > for project status. This will help the wiki page to be perceived as up to > date as it won't need to be updated with each bit of progress. > > -Ry > > > On Mon, Aug 3, 2020 at 4:29 AM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > > > 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 > > >
