Thanks Sylvia! Also, here is the video if anyone would like to view it: https://drive.google.com/file/d/1V1i_fpzo8ZhvEZYR-tbdarUsYK357xSR/view?usp=sharing
On Fri, Dec 14, 2018 at 9:03 AM Sylvia Tomiyama <sylvia.tomiy...@airbnb.com.invalid> wrote: > Here are the notes > < > https://docs.google.com/document/d/1xRLqmUn-G7WiPe8qZnfuvbrYHZ1jmk9aSv9Bhjis2tg/edit#heading=h.98sb4lvagu9j > > > from the meeting. Link is available to everyone, but also pasted here for > convenience: > 2018-12-13 Apache Superset Agenda & Meeting Notes > > Attendees: Jeff Feng, Conglei Shi, Krist W., Vyl C., Timi F., Grace Guo, > Alan Gates, Chris Council, Sylvia T., Max B., Chris W., John B., Justin M., > Beto, Christine Chambers, Junda Yang > > Agenda: > > - > > History of the Superset Project > - > > How does the mechanics of Apache work > - > > Hortonworks Engineering Apache Training > - > > Coaching on how to do things the Apache Way > - > > Options if not Apache > > > Meeting Notes: > > - > > History of Superset > - > > Max: People at Hortonworks approached Max/Superset to join the Apache > software foundation and support with the mechanics of joining > (mentorship, > committers). This is exciting -- Jeff and a few others at Airbnb had > been > working on Superset. Max had done this with Airflow before. These > people > didn’t actually come through -- a few people had made some commits, > and > some mentorship early on, but fizzled out. I didn’t personally show > leadership in getting people fired up about getting this graduated > from > incubation > - > > How does Apache work / Apache Way (Alan) > - > > No corporate affiliations: Corporations don’t have a standing/voice > as such in Apache. Each person participates as their own > - > > Companies can’t dictate how to act/vote. (they can, of course, decide > what they pay for). > - > > Releases are determined by the community, not by companies > - > > You can try to get a release if your company needs it, but need > community buy-in > - > > Can’t make promises about a release on X date, because this is > driven by the community > - > > Meritocracy -- people are recognized for “just doing it” > - > > Contributions come from more than just code: e.g. release plans, > proposals for features, figuring out use cases, qa, answering > questions, etc > - > > Contributors that show they can help guide the project you can > vote them to be PMC. In incubation, it’s PPMC - podling. PMC > has to approve > them and PPMC votes aren’t binding but it’s like practice > - > > Jeff: what is necessary for being voted into PPMC? > - > > Alan: depends on the PMC, but for me what I look for: they have > been a committer for a while. Know how to work well with > others. Can help > guide/lead others -- shoulder the burden of driving the > project forward. > Helping new people, coming up with ideas where we should go > - > > Committers and PMC members who contribute across projects can be > voted in as Apache members > - > > Collaboration > - > > Mailing lists are the official record -- if it didn’t happen on > the lists, it didn’t happen. > - > > Enable people around the world -- be inclusive. The way Apache > deals with this is ensuring everything is on teh mailing list > - > > Jira (and github) if it copies to mailing list as a record, it > counts. The point is that there is a record, and that I can > look into it > from somewhere else and see what happened. Archive > - > > Voting: typically do 72 hours so that there’s enough time/day > - > > Types: > - > > Dev - ideally put everything into here. > - > > Private - ONLY stuff that can’t be public; e.g. security, > legal, people. > - > > User - for users of a project > - > > Others -- commits, issues, security lists > - > > Decisions are reached by consensus, not by force > - > > E.g. releases and adding new committers or PMC members are > voted on > - > > Votes are asked for only after consensus is reached > - > > Max: Votes and meritocracy seem in conflict. > - > > Only PMC counts for personnel > - > > For code, committers > - > > PMC is for releases -- because this is a legal thing. But, > still do this in public > - > > Merit never expires (but people should use this > - > > How to get a sense of consensus before voting? > - > > Do a prevote: e.g. “DISCUSS” and get inputs; Then start an > official vote > - > > Need to create a space where people can comfortably stand up > - > > Can you vote on a release cycle and then get it approved > - > > Each release has to be approved > - > > But it’s fine to agree on trying to do a release cycle > - > > Note from Justin: Not everyone is paid to work at Apache -- there > are people who are doing this as a volunteer > - > > Justin: Also committer bar should be clearly documented > - > > May need to reduce the bar for this > - > > What’s the value of Apache? > - > > Known and respected brand in teh open source world > - > > Developing open source software owned by a 3rd party really helps > build collaboration. It’s very different if a company owns it. > - > > If users are coming to contribute, it’s important that it’s owned > by a third party > - > > Your users can become your partners and code contributors. It’s > the only time where I have a customer report a bug and fix it. > - > > Ability to collaborate in the open in a safe “switzerland” space, > with a friendly license for businesses. > - > > Which hat are you wearing -- for the people who are paid to work on > it > - > > Are you a committer? PMC member? You have responsibilities to > Apache. > - > > Just because the company pays you, it doesn’t mean you’re not > bound by your Apache responsibilities > - > > Justin: Incubator Wiki- Default Project Guidelines: > https://wiki.apache.org/incubator/DefaultProjectGuidelines > - > > Best Practices > - > > Make sure all off-list discussions are posted to the list, so that > people can be part of the discussions > - > > Discuss changes fully in PR > - > > Avoid: PR with minimal description, post a patch, and resolve > within 5 min. Because someone reading it can’t understand it. > - > > Ideally wait at least 24 hours before it can be committed > unless it’s some really serious issue. > - > > Participate in mailing list in constructive ways > - > > Be professional in your interactions at Apache. Also remember > that sometimes people end up being rude unintentionally > - > > Make sure all roles are represented in Apache > - > > Make sure to respond to feedback outside of the core community > - > > Vyl: Is Slack or other channels for communication OK? > - > > Alan: My perspective -- email is a specific way of implementing the > spirit of the law > - > > For slack specifically, I’m worried about the durability of the > content > - > > If you can download and archive it, that would work. > - > > Justin: there was a way to do it before > - > > Justin: Most/all release conversation should go into the mailing list > - > > Max: but what about real details like which cherries etc > - > > Alan: Some projects have release manager who is centralized > - > > Justin: Most projects I see, they discuss what features to include in > the mailing list > - > > You can do what you want as long as it follows the guidelines. > - > > Max: Not having support for images is really challenging esp with > data visualizations. > - > > Github is fine: Open and archived/durable over time > - > > Core tenets: Open and archived/durable over time > - > > Michelle: We use SIP for major changes. If we’re divvying up work, > then should that be archived? > - > > Alan: The easy way to think about this is, can someone who is not > physically located with you jump in? Can someone else join? > - > > John: For the SIPs -- we usually have some discussion somewhere that > the idea comes from, before the SIP, is that OK? Does that > somehow need to > be documented? > - > > Alan: If you design something top to bottom and have 10 pages of > documentation, then it’s really hard for someone to jump in > - > > Need to be not too far so that if feedback comes in, you’re not > willing to make any changes > - > > I think it’s fine if you have some discussions and put it into the > SIP > - > > Michelle: If we can’t find a way to archive slack. People go to slack > to get help from each other -- does that need to be archived? > - > > Justin: users asking questions on slack are fine, esp if it’s > quick and easy to answer. The downslide is that it’s not > discoverable so > it’s repetitive. So usually it’s worth it just to send it to > the mailing > list. > - > > Jeff: what about stack overflow? > - > > Justin: yes, that’s fine. It definitely attracts more people and > creates a bigger community. > - > > Max: Google docs is also a good forum -- is it OK? > - > > Justin: these are all fine, but you are having conversations that > people can’t join. This is why we don’t want to require > synchronous/realtime conversations > - > > Max: We need to ask Apache Infra for every piece of infra to add and > gets denied > - > > Justin: Autoclose issues. This is discussed in a lot of detail on the > mailing lists and the consensus is that it’s problematic > - > > CI tools are OK > - > > Not being admin on their own gitbox is challenging > - > > Alan: This is a common complaint from many other projects > - > > People who are not committers cannot manage/label issues on github > that are not their own issue. > - > > Justin: I think it might be an issue with setup. If they are a > committer they should be able to > - > > Vyl: I have submitted all my paperwork but I still haven’t gotten a > response over several months. > - > > Justin: PPMC not keeping roster up to date > - > > Alan: This is probably because the mentors aren’t active. > - > > Max: can we have a UI to do this? > - > > Justin: whimsy > - > > Max: Not sure who is on the mailing list > - > > Alan: some of it is the mentors, for sure. Also Apache is slow in > updating tools, which is why it’s > - > > Alan: please be honest. If Apache isn’t the way, then don’t hide > meetings. > - > > Justin: the problem is that having the meetings makes it hard for people > to join > - > > Meetings can’t be the driving force > - > > What would be a good process if we want to have some in-person > discussions? > - > > Justin: Sending an agenda out and letting people add stuff, and bring > it back to the mailing list works. Copy and pasting meeting > notes into the > mailing list is fine > - > > Release Process > - > > Max: There are hundreds of dependencies in the javascript tree that > changes all the time > - > > Justin: Why are you so worried about the dependencies? > - > > Max: I’m worried about managing the license file. > - > > Justin: It is only the bundle > - > > Max: Convenience releases. Do we need to build tools > - > > Alan: Are you worried that there is stuff in the convenience releases > that is not in compliance with Apache > - > > Justin: bsd with advertising clause is one of the few that matter. If > you want to be Apache software, it must be compatible with the Apache > software > - > > There are mutated versions of a known license, and I’m not sure how > to make the call on them. > - > > You can ask on legal-discuss. There are past questions there that > covers most of the cases. > - > > As long as the clause doesn’t add more restrictions, it’s generally > permissible > - > > There are 800 javascript libraries -- a micropackage world. > - > > Other projects have had similar challenges, e.g. maven. Maven has > some pretty good tools to pull in the licenses quickly and will tell > you. > - > > Justin suggests running fossilogy. It will also help with doing > deltas between releases. > - > > Github 5801 is where I put this in. I’m worried about having 20 > different conversations about this, especially since this evolves > - > > Alan: I know this is a painpoint. I spent an entire plane ride from > Toronto. You will get better at it over time. No matter where you > ship > this, it’s stuff you have to get right, since you’re liable if > you screw it > up. Someone has to bite the bullet. It can be more than just Max. > - > > Someone can own your software if you screw it up and you could get > sued. > - > > The nice thing about Apache is that people know for sure that it’s > safe to use. > - > > Justin: Also Apache protects all PMC members legally -- so even if > you screw it up, unlikely you personally would be sued. Of > course, this is > all under the assumption that you’re following the release policy. > - > > Alan: Apache legal resolved will show you what’s been approved or > not. This will answer 90% of questions. You can use discuss for > the > alternative/ > - > > You can also ask the owner if you can use it under Apache and > usually they say yes, or they can change it for other people. > - > > Justin will also share other tools and talks about how to do > releases. I’ve reviewed 4-500 releases. > - > > Justin: There are projects with more licenses, so it’s definitely > feasible. > - > > Michelle: Could we get it reviewed so we don’t screw it up > - > > Yes, that’s the point of us (Alan/Justin). > > Steps for a release > > - > > Releases are code only. No binaries > - > > A: I would start with the code release, then do the binaries later since > the code release is easier and very educational. Then non-conforming > licenses are out of the picture. > - > > Someone says on the list, I propose to do a release, and let’s use this > label or cut at Friday > - > > People discuss and come to a conclusion on where to cut the release > - > > Projects do their releases in their own way > - > > Release Guidelines: > https://incubator.apache.org/guides/releasemanagement.html > - > > Have disclaimers, notice -- there’s documentation > - > > Build release package of source code (not compiled , no outside > packages) > - > > Sign that with your PGP key and sha512 > - > > Put this up on a page and tell people, here it is, go vote on it > - > > Tarball, gzip package > - > > Signature > - > > Sha hash on the package -- to check you build it and it’s what > you say it is. > - > > Ideally we would have people test it at out this point > - > > Since incubating, need our community to vote on it. > - > > Then send email to incubator pmc to get votes on it, then done > - > > Can ping gates@ for links for what to go in the notice file. > Alan/Justin: notice should be simple for your case. > - > > Copyrights that have been relocated from source file > - > > Any required third party notices that aren’t already mentioned in the > license file > - > > If there’s > - > > Date is 2018 > - > > Justin also sent links for all this > - > > There is also another repository where we store javascript plugins. > Should we regard this as an external dependency? > - > > Alan: Who owns that code? It’s up to them where they want to put it > - > > Justin: It might be owned by the company who paid them to do it > - > > Max: we refactored some sections and took them out to enable > embeddable charts. Some of it is a copy and some of it is > refactored copy. > - > > Do we call it Superset plugin > - > > There’s no requirement that Superset is one thing only. You don;t > even need to release them together. Being pluggable. > - > > Justin: It’s not something you need to figure out for your first > release. But what matters is if it’s an optional? If it’s not > optional, > then is it still under Apache? Then it’s not a problem. > - > > The license and notice should cover everything that is in the release > - > > Moving it out is concerning if you’re using it in private > - > > Justin & Alan: This is a place to learn. It’s better to do the first > release, even if all yoru ducks aren’t in a row, and learn from it. > That’s > the point of the incubator. If it’s really out of bounds > - > > Release what you can today and > - > > I don’t think we should move forward in this frankenstein mode. > - > > Max: if we commit, we should fully commit > > > Other options > > - > > Alan: Other projects have certainly left Apache and gone their separate > ways. There are other software foundations or you can go it on your own. > - > > Speaking as a person who has been doing this for a while, I think > being part of something is definitely needed, because otherwise > you’re > reinventing the wheel > - > > Max: how do we decide this? > - > > Alan: Whether we shut down is the PMC. > - > > If half want to stay and half want to leave, we probably wouldn’t > kick out > - > > Jeff: Who is the community here > - > > Alan: Binding votes are PPMC, but I really hope that community can > come to a consensus we can > - > > Previously retired podlings: There are some that left. Not clear if > Apache would care about the name since it hasn’t been released. I > don’t > think Apache would make it painful > - > > Justin: I don’t think name would be an issue because it hasn’t > been released and hasn’t been trademarked. > - > > Trademark is only done manually after release with a specific > request. Organizations can pay for it adn donate it to Apache > - > > Max: If people want to stay in Apache, I want to make sure that more > people are helping with it. > - > > Jeff: how much work is it? > - > > Alan: the first one is different from all the other ones. I would > assume it’s a solid week of work. After that, it’s one day. > - > > First time I did a pig release, the > - > > Jeff: it seems like release process would be equal amount of effort re. > Releases. > - > > Alan: Some things are more lightweight, other things are more > intense. E.g. blackduck that looks for copyright violations. You > can bring > your own governance model. > - > > It’s definitely different. There’s a lot more of you define your own > process vs. > - > > Jeff: If there’s a will to move forward, can we stay? > - > > Justin & Alan: Yes > - > > Max: But, we need to commit or get out. > - > > Justin: how any of the PMC are on the incubator list? > - > > Do you read the board report -- reading this would help with > clarifying the ultimatum > - > > Alan: this doesn’t show up in the emails. Everyone has access. It’s > published on the website. Or stored in SVN > - > > Jeff: I’ve been creating these reports but it’s been going to a black > hole. > - > > Alan: OK, we need to close the loop on this > - > > Justin: I recommend adding more people to the PMC if you are stretched > thin. > - > > Apache Incubator Board Minutes: > https://whimsy.apache.org/board/minutes/ > - > > Alan: A +1 means both that you’re behind it and willing to support it. > - > > Jeff: i don’t think it’s from a lack of commitment or lack of > willingness to play by the rules, but more lack of mentorship. > - > > Max: I felt like this face to face meeting really helped, in a way that > was hard on mailing list > - > > Alan: I encourage people to go to Apache con -- it helps with this sort > of thing > - > > Alan/Max: We should discuss this decision on the mailing list > > Action Items: > > - > > Alan to send a release checklist to us > > > On Mon, Dec 10, 2018 at 9:54 PM Jeff Feng <jeff.f...@airbnb.com.invalid> > wrote: > > > Hi All, > > > > The PPMC and Committers <https://whimsy.apache.org/roster/ppmc/superset> > > on > > the Superset project are going to be meeting with one of our mentors > (Alan > > Gates) to receive coaching on learning the Apache Way as well as aligning > > on a set of next steps forward. > > > > All are welcome to join and participate in the meeting. It will be on > > Thursday 12/13 from 2-4 pm PDT. I have included the WebEx information > > below. We will share a summary of the meeting with Alan following the > > meeting back to this thread. > > > > Best, > > Jeff > > > > > > JOIN WEBEX MEETING > > > > > https://airbnb.webex.com/airbnb/j.php?MTID=ma4a1fd711d92662580330f1c44859977 > > < > > > https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fj.php%3FMTID%3Dma4a1fd711d92662580330f1c44859977&sa=D&ust=1544909323375000&usg=AFQjCNGaBqzmCnnq81Pz8XYy1ROSTxow9g > > > > > Meeting number: 626 615 201 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial > > sip:626615...@airbnb.webex.com You can also dial 173.243.2.68 and enter > > your meeting number. JOIN BY PHONE 1-650-479-3208 Call-in toll number > > (US/Canada) Tap here to call (mobile phones only, hosts not supported): > > tel:%2B1-650-479-3208,,*01*626615201%23%23*01* Global call-in numbers: > > > > > https://airbnb.webex.com/airbnb/globalcallin.php?serviceType=MC&ED=745271162&tollFree=0 > > < > > > https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fglobalcallin.php%3FserviceType%3DMC%26ED%3D745271162%26tollFree%3D0&sa=D&ust=1544909323375000&usg=AFQjCNFnSd37so63klXA4nIC742NUhKwEg > > > > > Can't join the meeting? https://help.webex.com/docs/DOC-5412 > > < > > > https://www.google.com/url?q=https%3A%2F%2Fhelp.webex.com%2Fdocs%2FDOC-5412&sa=D&ust=1544909323375000&usg=AFQjCNFkGvqMS8Pu5vSMnaOEDO65yGppAA > > > > > > > > > > > > > > > On Thu, Oct 25, 2018 at 2:40 PM Alan Gates <alanfga...@gmail.com> wrote: > > > > > All, there are concerns in the Incubator that Superset is not learning > > the > > > Apache Way as it should. > > > It is still doing non-Apache releases. Some have pointed out evidence > > that > > > decisions may be being taken off list and corporate allegiance may be > > > determining peoples choices. If Superset is going to move through the > > > Incubator and eventually graduate it needs to begin addressing these > > issues > > > immediately, as the Incubator PMC is loosing patience. Alternatively, > > > maybe Apache isn't the best home for Superset, and if so, that's ok. > > > > > > The purpose of this email is to start a discussion around what the > > > community needs to do to address these issues. > > > > > > Alan. > > > > > > -- *Jeff Feng* Product Lead m: (949)-610-5108 twitter: @jtfeng
