Tip:
Highlight text to annotate it
X
Jenny Donnelly: Now we're going to kick off the Town Hall. I've asked Andrew who joined
the team about one year ago as our community engineer, and he's really put so much effort
towards building bigger and better relationships with the community. We decided that it was
a big enough function that it required a dedicated person to make sure that community needs were
being heard and met and pull requests were being fostered into the system and all that
sort of good stuff. He's put a lot of effort into growing the community over the past year
and I hope you can see the difference.
He's going to walk us through what the past year has been like in that regard, a little
walk down memory lane for the past year from a community perspective. Then we'll kick off
after that into the more informal discussion that we call the Town Hall. Take it away.
Andrew Wooldridge: Alright. Yay.
[applause]
So to kick things off, this talk is entitled YUI in 2013: A Year in Review. I'm Andrew
Wooldridge. You can see I'm @triptych, you can probably find me on IRC, on Twitter, all
over the place. I am the YUI community engineer. As I said before I do a lot of work behind
the scenes to make things smoother for everyone involved in the community and on the team
to make the process go quicker and faster.
There are some trends this year I want to go over. The first one was the trend of rapid
releases. This year we saw a lot of streamlining of the process by which we come up with releases.
I'll go into these in more detail.
The second one is the increasing community involvement. There was a larger number of
people involved, there was a larger number of pull requests, a larger number of people
outside of the core YUI team getting involved in the community.
Another trend this year was out with the old, and I'll go over that in more detail shortly.
Another trend was in with the new. A lot of new features, a lot of new people, a lot of
new ideas coming in.
Another trend this year was performance. There was a lot of work done early at the beginning
of this year to radically improve performance for YUI.
Another trend was continuous integration and testing. A lot of things that happened behind
the scenes that you may not see as an outside contributor, a lot of this stuff that I'm
going to go over will deal with that continuous integration.
Lastly I'll go over some community stats, some of the things that you may not necessarily
on a day to day basis see that it's going on behind YUI.
The first trend was rapid releases. Between the last YUIConf we had 11 full releases.
That was YUI 3.8.0 in late December and then all the way up to 3.13.0 not too long ago.
In between those we had 8 preview releases starting in January. The trend has been at
least one to two preview releases per full release. The purpose for these pre-releases
has been to give the community an opportunity to check out the release, see if there's any
bugs, try it in their own production environments, and to really help us make each release a
great one.
The next thing that I wanted to go over is there was a new short-lived release branch.
This was a big change for us near the middle of the year, and it was due to a topic brought
up by Ryan on the yui-contrib list where we create... In the past when we were doing releases
we would close the tree down, both the 3.x branch and the dev-master branch so nobody
would be able to check in anything for almost two weeks. If you had a pull request pending
and you missed that cutoff point, you had to wait upwards of three weeks.
Due to the change that we made where we only closed the tree for a single day or so, we
would create a cut of release branch based on either dev-3x or dev-master. These two
branches are either like a stable branch that we can only check in small fixes to or in
case the dev-3x is a more progressive branch or had a lot more features in it. Regardless,
those would be closed down, and people would be frustrated about the fact that it could
be three weeks before your pull request was brought back in.
This new methodology allowed us to just close the branches for a day, cut a new release
branch, we'd do all our work on that short lived release branch, and then after release
that branch goes away.
When I was doing the review for this talk I had some feedback saying you know, you should
come up with a really great graphic to show this difference between the old way and the
new way. But I found a better way to illustrate that, which was imagine your pull requests
waiting for the release branch and then finally your... The idea was to get rid of this logjam,
so that was a big change.
Another trend this year was the pull request reviews. It used to be before there was a
dedicated person for this, pull requests would potentially wait in limbo for eight weeks,
a month, two months, a year, before they would get some attention. Especially for community
pull requests.
One of the things we changed this year is we made sure that every week we go through
all the pull requests and if there are any ones that are stale we find out what they
need to get those back working, or we need to find out if that person needs unit tests
or if they need to update their code. This has been a really big change and I think the
number of pull requests that are stale has dropped dramatically.
Also we added a CONTRIBUTING.md. Basically what this is, if you're familiar with GitHub,
if you have a CONTRIBUTING.md in your repo before any pull request is made there is a
link to this document, and the document spells out exactly what you need to do to create
a good pull request. It could be that you need to have unit tests, it could be that
you need to make sure that you check in only source versus build. But basically this has
helped in many ways because people would be checking into the wrong branch, or people
would write pull requests that needed a lot of work before they could get into the tree.
This has helped streamline that.
Here's an example of a great pull request. This is from Satyen. It's an example of one
that had a huge number of participants, it had a lot of back and forth, it had a lot
of community involvement. If I were to scroll this down you'd see there's just lots and
lots of comments, and it's an example of just a great pull request that got pulled in and
contributed greatly to the repo.
Across the entire YUI organization, all the different repos that we have, we have 12,128
watchers and 3,459 forks. That's a lot of activity, it's a lot of people looking at
this code, a lot of people interested in the things that we're working on.
There was an increase in the CLAs. CLAs are Community License Agreements where if you
want to check in code to a repo you need to sign this agreement that basically allows
us to use your code. There was an increase this year of 74 out of a total of 318.
Another topic, we opened the committer list. This was a big deal for us. Traditionally
YUI has had committers that were basically Yahoo employees. Now with the introduction
of new reviewers and new committers that aren't necessarily even affiliated with Yahoo in
any way, we're truly becoming an open source project. This comes along with the CONTRIBUTORS.md
which lists all the contributors.
I think it was in March, I believe, Luke and Ryan were added from SmugMug as full reviewers.
This shows that we are really serious about having third parties and other members of
the community as critical components of the contributing process.
We also added other external contributors which I'll go over shortly when I get to them.
Another thing that we are adhering to is the new contributor model, which gives you a path
to become a committer. I want to read this out to you because it's really important and
it shows just how dedicated we are to having community involvement that's not just specific
to Yahoo.
It says Ĺto become a committer one must have shown a willingness and ability to participate
in the project as a team player. Typically a potential committer will need to show that
they have an understanding of and alignment with the project, its objectives, and its
strategy. They will also have provided valuable contributions to the project over a period
of time and, specifically, a minimum of 10 qualifying pull requests. What's a qualifying
pull request? One that carries significant technical weight and requires little effort
to accept because it's well documented and tested.'
You'll notice there's nothing in there that says you have to be a member of a certain
company, you have to be with a certain organization. It's purely based on the quality and the number
of your pull requests.
Here are some committer stats. We have 4 reviewers right now, 17 committers, and added this year
we have Caridy who's been added to the committer list, Juan Dopazo, Clarence Leung, Ezequiel,
Eugene, and Ryuichi. Ryuichi is also significant in that he's another non-core Yahoo employee.
He works out of Yahoo Japan. He had a number of significant contributions to the code base
and he was recognized by being added as a committer.
Another trend that we have for this year is out with the old. On the community side of
that we deprecated our old forums, and I'll also go into more detail as we get to the
in with the new. We deprecated Trac, which was traditionally our old bug tracking system.
We moved to GitHub which I'll also explain shortly.
In YUI 2 we moved the downloads for the YUI zips. We archived those and placed them on
GitHub, so if you go to GitHub.io you'll be able to find those there.
We also moved the documentation to GitHub so that not only is it open sourced but it's
also in a place where it helps with the next one which I'll explain. We are going to be
moving the documentation off of YDN and onto this GitHub.io site, which will allow... There's
an ongoing problem right now where when you do searches for YUI code base you'll tend
to get YUI 2 results. This helps with SEO and helps us elevate the YUI 3 results instead.
Also with YUI 3 in terms of removals, here are some of the things that we took out of
the code base. We removed SimpleYUI, Profiler, dom-deprecated, node-deprecated, datatable-deprecated,
and uploader-deprecated. A lot of this was like clean up. These are things that have
probably been in there for a while that we finally decided it's time to be serious about
simplifying the code base as well as moving on to newer and better things.
New deprecations. YUI 2in3 has been deprecated. Substitute is now deprecated. It's recommended
that you use Y.Lang.sub or Y.Template instead. CSSBase has been deprecated. It's been replaced
with Normalize.css.
This is something that happened early in the year, but we used to use Ant for builds and
now builds are using Shifter with Yogi, and releases are now using Grunt with more to
come with Grunt.
But this is also a big deal because builds would take a long time to run. It can take
I think half an hour, forty five minutes. Now they run really, really quickly, and this
is really helpful with the CI situation.
We've also removed all the SWFs from the repo. We've created a new yui3-swfs repo that contains
the uncompiled source, so if you want to have SWF capabilities in your YUI code you can
go to this repo, compile it and host it yourself.
We also deprecated node-menunav and arraylist-filter.
Also out this year from YUI, we removed... One of the things that we constantly kept
up to date is our target environments. We constantly look at market trends and how much
usage each one of these devices gets used. What we end up doing is... Sorry, I need to
take a drink here, take a breath. We want to focus on the environments that are getting
the most usage and the highest market share, so we've removed these and we're focusing
on... We've removed Android 2.2, iOS 4.x, Node.js 4 and Node.js 6, and we've added Node
0.10.
We've also deprecated PHP Loader. This is another example of a long standing project
that is a sort of language for a while and we're now officially deprecating it.
I feel like this one's a real win. YUI Compressor was something that we'd decided to deprecate,
but there were a lot of people in the community that really wanted to keep this up and running.
This now has a new owner and it's now fully community managed. I'd like to thank Joey
Smith for taking that up and running with it. It has had new builds since he's taken
ownership of it, the documentation has been getting up to date. I really feel like this
is a win for us because it's something that the core team doesn't necessarily focus on
now but the community has picked this up and run with it.
In with the new. We have new team members. I'd like to welcome Eugene Kashida this year.
He came in February, Caridy Patino in April, Clarence in June, Ezequiel in September, and
Juan in October. Eugene came from another team inside Yahoo and has been focusing on
the project where he's working on simplifying the rollups for YUI. The URLs that you see
when you do a combo URL, he's working on simplifying that and shortening it. This can have a huge
impact on performance because you'll be making less HTTP requests.
Let's see, our two newest team members. Ezequiel has been working on diving into the code base
and finding all kinds of interesting obscure bugs and really helping us clean up the old
and decrepit bugs that have been sitting around for forever.
Our most recent entry, Juan, is an example of one of our community members who's been
long standing, he's been on IRC for forever, he's been making great check-ins, and now
we've brought him into the team.
Clarence, you know about Clarence. He was a... What do you call those? Intern, intern.
He was an intern for the longest time. When he joined in June he really hit on all thrusters.
He's been getting involved in every aspect of the project. He's been writing new specs.
You see him on the open roundtable talking about new things. He's getting involved in
every process from doing builds to pushing gallery builds. He's just been really hitting
the ground running.
Caridy joined us from Search as well, and he's been working on the Mojito side of things
which you may hear about later on today, or later on.
Further on with in with the new, we switched to GitHub issues instead of Trac. All new
issues that get filed now for the project are filed through GitHub. This has really
helped in many ways, especially with YUI becoming... It's always been part of an open source community,
using GitHub issues allows us to be familiar to other projects. I guess what I'm trying
to say is if you're working on other GitHub projects you're familiar with how GitHub issues
works. Before now when you would cut switch to YUI you would have to use this weird Trac
system. Now since we switched to GitHub issues it's a lot more streamlined. You're sort of
like a first class member now.
We also are taking advantage of the labels in GitHub now for things such as enhancements
and regressions. We also use it for our sprint tracking. If you look in the tags you'll see
there's things like to do, or done, or completed. We use that to help with our internal tracking,
and it's been really great.
More new stuff. We moved the community forums to Google Groups. Yui-contrib has been around
for a while, it's not new this year. But we had 63 new members for this year for a total
of 109. This list is amazing. This is basically the place to go for finding out what's hot
and what's going on at YUI. A lot of things, a lot of initiatives that started in YUI,
a lot of new features started as a thread in yui-contrib.
If you're working on something like a gallery component, or if you're working on a new feature
that you'd like to bring into YUI, this is the place to bring up the topic and to allow
others to basically get feedback about what you're working on. A lot of these things,
what will happen is it'll start off as a thread in yui-contrib and then it will move to a
pull request.
Yui-support is one of the new forums that we created. This is basically replacing all
of the current support that you would have had on the traditional forums, things like
YUI 3, all the current projects that we have. Right now it's up to 150 forum members and
it's only a few months old.
We also have another group called yui-deprecated. This is for all of our deprecated products
such as YUI 2 and YUI Builder.
New components this year. Y.Tree introduced by Ryan. A+ Compatible Promises, it's been
an ongoing project with Juan and a number of people in the community.
Paginator and DataTable Paginator, this component was created by Tony. It's sort of a side project,
an addon to the work that he was doing with DataTable. He was focusing on DataTable and
he felt like there was a real need for this component in a way that was not necessarily
tied directly to DataTable. This is a great example of where a new component emerged out
of a need that we had.
Improved components. We have a dramatic improvement to the inline editor using content editable.
This is another example of a great effort from Iliyan with some help from Tony. It's
a great example of a community based project that got put onto core, and it's a great feature.
This feature is basically... Traditionally if you had an editor component you had to
use iframes. Now you can use an inline editor that can take advantage of the CSS and the
styles that you have on an existing page so you can do things like inline editing. You
can click on an element, edit it, and revert it back. You won't have to worry about the
overhead of having iframes.
There are DataTable improvements from Tony as well, additional things such as selection.
There were Charts improvements from Tripp. There was a lot of behind the scenes moving
around of components within Charts to improve performance.
And lots more. There were a ton of things. You guys made a lot of hard work for me every
release because there were so many new components and so many updates for every release, and
I would go through all the history files and I would find all these countless contributions
from different contributors. I think it's great because every time we do a release it
gets more and more, so I'm really excited about that.
In Gallery we had over 127 new modules with over 78 of those hosted on the CDN. We also
improved the deployment process for the gallery. The number of people that are involved in
doing gallery pushes now is dramatically increased. There's Clarence, there's Eugene, there's
Tripp. This was basically something that only a couple of people were doing. If for some
reason those people were not available then say a gallery push wouldn't go out, but now
we've dramatically improved the number of people that are doing this. This has helped
streamline the process and it's going to help us moving forward when we move to improvements
to the gallery.
Another big thing that happened this year is Pure CSS, or Pure basically. As you can
see it's a set of small responsive CSS modules that you can use in every web project. This
is a great new project that we've been working on that is a very small core component that
you can use in CSS to create responsive websites.
Pure is amazing. There was a day that we were joking, we were following along on GitHub
the number of watchers and forks. The day that it surpassed YUI was like, you know,
this moment where they were like yeah, check it out man, Pure just beat YUI on GitHub.
Already it's at 6,269 watchers and 741 forks, and it continues to grow daily.
There have been 3 full releases of Pure with 5 preview releases. There's been a huge community
response. When I was tracking this on Twitter the day before it was going to get launched
I think it got leaked on Hacker News, and the number of tweets for it just exploded.
I think that sort of helped, having this idea that you were discovering something ahead
of time.
There's been a huge number of designers and developers giving feedback. There's been a
lot of great work. This is an example of a project that is basically reflecting a new
strategy for Yahoo with building new projects or products.
It also is reflecting new best practices using Bower and Grunt in the development process.
Another trend for this year was performance. Event and event-custom had speed improvements.
Y.Base and Y.BaseCore had over 4x improvements over 3.8.1. Y.MyModel, which is basically
creating your own model with two attributes, there was over 2x speed improvement.
I want to refer to Eric's talk about this back when 3.10.0 came out to give you more
details about that.
Another trend for this year was continuous integration and testing. This is something
that, like I said, happened behind the scenes. Every time anyone would check in something
in the code base, it basically it triggers a new CI build.
I'm going to show you something that Reid's been working on. It's called the Testing Dashboard.
This dashboard is a quick way to look at the different branches that are being tested on
a daily basis. Every time that there's a new commit you'll see that the tests are triggered
and you can immediately discover if something you did caused a regression or some new tests
are failing. Also if a particular operating system didn't get tested yet or if there's
an issue with flaky tests, which I'll go over shortly.
Over 10,000 tests are run in every environment, so every time there's a commit it does over
10,000 tests. This includes over 1,700 functional tests.
Another effort that went into this year has to deal with unit and functional tests. One
of the issues we have with, say, testing on Android or testing on a newer operating system
is that we would come up with tests that would fail in CI but not fail locally. Part of the
problem for that had to deal with the way that tests were created. Some of the tests
depended on external APIs like say GitHub API or some other REST API. When you ran that
in CI you would reach rate limiting, so the test would fail.
We called these tests flaky tests. These are tests that would either fail intermittently
or they'd fail only say, for IE6, but when you ran it locally it would work fine. We
did a lot of work to reduce the number of these flaky tests, and also to overall look
at how functional tests and unit tests are created and come up with a better way to make
sure that new tests that are created don't have this problem.
Here are some community stats. From release 3.8.0 to 3.13.0 we had 19 contributors, 2,925
commits, almost 3,000 files changed in YUI. Overall, in the entire life of YUI, there's
been 23,000 commits by 161 contributors. This represents almost a half a million lines of
code and it took an estimated 226 years of effort. I know that a lot of developers here
are going yeah, that's my 100 years right there.
That's it from me. We're ready to open up the Town Hall Roundtable and let's get started.
Jenny: To kick things off I would love to hear from you guys if the things that Andrew
was talking about about the changes to our processes and the opening up of the community,
if you guys could see and feel that from where you sat across the IRC client. I'd love to
pose that question to you guys to kick us off.
Andrew: I love how this works. We start things off and people are like oh I'm going to be
shy, I'm not going to say anything, I'm too busy. And then we get warmed up and everyone
starts getting questions going. We're going to skip the warm up time, so tell us, what
did you do this year? You were really busy this year working with YUI, so tell us. Did
you feel these changes?
Audience member 1: I hadn't submitted pull requests before you guys' contribution changes,
but I submitted two and the process was really convenient. The first time I didn't create
documentation or unit tests and I think Clarence or maybe someone else wrote them for me.
[laughter]
Andrew: You hear that? Everyone else doing a pull request, go bug Clarence for your documentation.
Audience member 1: Well I'm not sure if it was Clarence. But the second time I could
emulate what they did and submit it. The person thanked me for having documentation and unit
tests on my own, so it was pretty nice.
Jenny: Thanks for that point. I would like to point out that we're going to have a talk
from Evan about documentation as a follow up to last year's most popular talk. Because
documentation and testing is something that's really important to the core team, and I think
part of this process means you are now being evangelized on the importance of these things.
Hopefully we're spreading the message to a point where it becomes second nature to you
guys to be submitting code with unit tests and documentation properly.
Manuel Jasso: Thank you Jenny, and thank you Andrew. As someone that has been watching
the YUI team growing and changing for many, many years, I can just tell you that the improvements
in the last year and a half are huge, are tremendous. I think it's the most I have seen
the changes.
I value very much and appreciate the openness that I see. It's so much easier now to go
just to GitHub and to see a pull request and to see a ticket and what tickets are being
opened and all the things. Three or four years ago it was still very obscure and I couldn't
really tell what was going on. Right now it's so much different and it makes it very easy
for us on the user side to plan what's coming.
The documentation is definitely one of the biggest factors for me that is important as
well as the testing. I can go and tell my management people that I work for that I can
rely on YUI because not only I read that it's well tested and documented, I can point people
to these open URLs of whatever. It's so easy now to see that so it's very, very valuable
and much, much appreciated. Excellent job there. I don't really have any feedback other
than keep it up.
Maybe the only thing I would probably think is missing, and I was talking about that with
Ariya, is that I think bringing Andrew to the team was a great addition as a community
manager, so that was an excellent move. It was a missing role and I can see that the
gap has been filled. Probably now we would like to see more in the product management
side, the marketing side, the selling part. Because YUI, I think it's much better than
most people know, so I think it would be great if you can do a better job of selling it.
It sells itself because it's so good, but I think if you also have someone dedicated
it will also make a huge difference. Thank you.
Andrew: Yeah, I want to make a quick comment about that. If you look at how Pure was introduced
and how it's being marketed and the target audience it had for that, it shows an example
of the change that we're making. We're creating things that are more specifically targeted
to a particular audience. Just the popularity of how that took off is an example of that.
Jenny: I would like to say that we are actively interviewing for a product manager for the
team. It's not an easy position to fill because it requires a certain amount of frontend technical
expertise but then the product management chops also. So if you know anyone that might
fit that bill, please send them my way. That would be greatly appreciated.
We have some of the world's greatest critics, and I mean that sincerely in terms of timely
direct feedback that helps make the project better. So I would love to hear about some
of those pain points or things that are bothering you that we might be doing better, anything
that might be on your mind in that regard too. Please don't be shy.
Luke Smith: I was just curious if there is an update on the Gallery?
Jenny: Thank you for bringing that up. Yeah, to be honest, Gallery is something that has
slipped lower on the list unfortunately, based on just all the things that we're working
on. We have unfortunately left it in a state of limbo. Navigating from all the infrastructure
that's on YUILibrary.com and moving over to GitHub puts us in a state of transition where
we're in between two login systems, for instance, is one pain point that we need to finish navigating.
So there is some work still that needs to be done to be in a position to even launch
a gallery V2. That said we have put some work into that, so we're in mid-stride, but at
the same time it's not at the top of the list resource wise.
One thing we're keeping in our minds right now is this new module system that we're really
excited about and what that means for gallery modules, for instance. We're in a difficult
position where if we went ahead and finished that work that we're in process with it would
actually take away from some of the next gen stuff that we're excited to get moving forward
on. So if I had infinite resources I would do both, but right now it does seem like stealing
from Peter to pay Paul. That's the dirty laundry that's under the hood right now.
That said, I think we have some ideas of using a redesigned gallery website as a dogfood
application for some of the other stuff that we're working with. We do see some potential
lower hanging fruit to get to something where you can have a beautiful new gallery website
that shows off modules in a good way that we're lacking today.
We feel really good about the deploy process for Gallery. Like Andrew said we've made some
investments in making the process a little bit smoother, having people be able to point
to GitHub repos rather than add code to a monolithic gallery repo. Those are good infrastructural
changes that aren't necessarily on the surface. We would like to have a beautiful website
to be the frontend to that that we're kind of maybe stuck on a little bit.
I will be very honest with you and say this work is not happening today, but perhaps by
the end of the quarter we can make some progress on other things that we're working on to make
room for that.
And then the other thing we talk about of course is open sourcing the whole project.
But that might work better in theory than in practice when it comes to an actual serious
project that needs to get done and needs to get done in a certain coordinated fashion,
just using people who are working on it on the side out of the kindness of their hearts.
I mean let's put it back to you guys. If you are able and wanting to participate on a project
like that, let me know. Let me know today, let me know offline, and maybe we can get
something like that coordinated in a more distributed fashion. It would be very ambitious,
though, to come up with the whole design implementation and launch of a whole project in a distributed
fashion. But it's something that we might be willing to consider because there's so
much need for it and the right people are here and in the community to help us.
So that's definitely a conversation I'm willing to take on. Maybe squeak a little louder if
that's a pain point for you so we can hear you better.
Luke: Okay, just to repeat what I said. If we're lacking people resources on the team
in order to do it internally, is there a possibility to bounty it out? So you can say we want it
done and we would like it done in an open source way, if you would like to do it for
us then we can either pay you for it or there are some other sorts of benefits to having
it done so that the internal team's resources don't get consumed for doing that.
Jenny: Are you starting a negotiation?
[laughter]
I mean anything's possible in terms of discussing options, but it does require at least two
to tango. If you are interested let's start a conversation.
Ryan Grove: So maybe a bigger question would be should there be a gallery, or should we
just use something like NPM or Bower component or some combination of those. Instead of having
15 different package managers and adding a gallery on top of it, let's use one that's
already gaining popularity maybe.
Eric Ferraiuolo: Yeah, that's been one thing I've been thinking about is allowing people
to also release their modules on their own schedule using Semver as the contract for
how these gallery modules relate with each other. Where right now you just have the one
gallery build tag and it's hard to really mix and match.
Then also with... We're not going to be hosting third party JavaScript code over SSL on the
CDN, so any website that all of a sudden... Most websites now at least have one page that
requires SSL or web applications you have to log in to, if not the entire application.
So you're quickly at a spot where you need to host these modules yourself. If we can
hook into something like Bower, NPM, it could more easily allow you to bring this code into
your application where these sorts of infrastructure pieces didn't really exist at the time the
Gallery was originally created.
Luke: Well now I'm curious. I actually think that sounds really promising. I'm really curious
about the thoughts of the other folks in the room that are either maintaining local installs,
they have some HTTPS hosting concerns or have asked for those sorts of things, if a local
install solution where the Gallery went away and there was a different distribution model
for either over Bower or NPM or something like that, if that sounds appealing to the
other folks in the room.
Audience member 2: I'm in the position of trying to convince some of my colleagues to
use YUI, and the more that you adopt tools like Grunt and Bower the easier the argument
is because it's less scary to them. One of the problems that it has is if we do develop
stuff for the gallery right now it's a big difference way of doing things, whereas if
it's just a Bower package, great, if it's just a Grunt package, great.
Daniel Stockman: In a similar vein, at Zillow we use a few gallery modules but we basically
copy them into our own private gallery and then override the group config and it's in
a way very brutal, but it's worked for years. Having a component Bower, whatever, NPM, would
be pretty awesome actually, especially the differential advancement through Semver would
be pretty cool. I could just justify a lot more effort spent towards open sourcing some
of what you would consider private gallery modules that we've never found enough time
to open source if it was something we could do in a more reliably distributed easily versioned
way. Yay.
Manuel Jasso: Yeah I actually like that idea a lot of being NPM, Bower powered, because
back to your question, we have internally the whole ecosystem of YUI internally. It's
all under our umbrella, HTTPS, and we even have a gallery complete. Well not a whole
gallery, but we have a gallery infrastructure in place because we have so many application
teams and they also want to share code among themselves. We're talking about like 80 or
100 teams.
And then of course the chances of someone wanting to create a component that 10 other
teams use is super, super high. We are putting a gallery infrastructure in place pretty much
as we speak, and we're already struggling with the model itself. So that's very, very
appealing. Anyone that can continue that process, thank you for that idea.
Luke: Eric wants me to say Grunt plugins.
[laughter]
Eric: Like we would still want a UI for discoverability over top of these gallery modules, and that's
where we could take something more like the approach that the Grunt plugins website does
where people are still managing these NPM packages themselves and putting their stuff
on GitHub and NPM. And then there's a frontend website that allows you to easily search by
searching through NPM to grab all the modules tagged with the Grunt keyword. We could do
a similar thing with YUI, YUI Gallery.
Luke: But then at the end it does end up still needing the UI resources, or the resources
to build out the UI that sits on top of that. But we have Tilo.
[laughs]
But presumably that type of work would be easier than building out over the top of a
custom infrastructure for managing modules, so that should be significantly less resource
intensive. So yay, it sounds popular, if by a vote of like three people. All opposed?
Andrew: I have a follow up question for that as I move away from there. One of the things
I'm really curious about with the community is I've heard that people are saying oh we
really want to use YUI internally or we want to use it for this project but there's this
thing that keeps us from doing it. Related to Gallery, are there other things that are
preventing you from adopting YUI internally into your teams? Everyone's giving significant
glances here.
Audience member 3: I'll relate just a little bit of our experience. It was unfortunate
when Google stopped hosting YUI 3x after I think it was like 3.7 because it was not very
nice to lay up on HTTPS. So we had to bring that in house and do our own combinator of
downloading the modules, precompiling them into a nice compressed package and putting
them out. But it wasn't necessarily something we wanted to do. But that's kind of a hurdle
little bit to the HTTPS and to the Gallery package usage.
Caridy Patino: About that, we are investing in the infrastructure for people to be able
to build YUI applications, and I'm saying build YUI applications in reference to production
quality, getting the pieces that you need using Grunt, something that will build that
application, get all the pieces ready, and then get you this piece of code that you can
push into CDN or push into your own Orion server or whatever you want to do with it.
But getting to the point where the quality of the application and the quality of the
code that you have is built by using all of these good practices that we have been learning
over the years. We are getting there. I'll be sharing a little bit more about some of
those pieces today, but in the next few months you will see more and more tools that will
allow you to do that kind of thing, like getting the application ready to push it to production,
getting it ready in CDN with the pieces that your application uses rather than all the
pieces that are available out there.
Yeah, we call it Express YUI but we'll talk about it.
Andrew: You guys are giving me exercise today.
Jenny: I think the original question also had an SSL aspect to it, is that right? Yeah.
Historically we've kind of come out and said SSL is a secure exchange and philosophically
we think if you're running an SSL application you should host all your JavaScript in order
to maintain that level of trust with your end user. That's where we are today still.
The conversation can still continue and we can keep discussing the security, the philosophical
versus the tactical need of hosting SSLed assets on CDN. I just wanted to give the historical
perspective.
Manuel Jasso: Actually, something about a reaction from what Caridy was saying is that
I'd like to maybe ask the YUI team to think and to maybe talk about or think about not
only that people will build applications on top of YUI but people will build whole other
frameworks and libraries on top of YUI. I also know that the Alloy team is doing something
that we're doing which is building their own thing on top of YUI.
That is tricky because... And it's probably just a mentality thing, which is don't think
about just letting people build apps with with YUI, let people build frameworks and
libraries on top of YUI and then build their own applications. That layer on top has been
challenging for us to do. Still, it was something that we were able to do.
Especially for large enterprises where we cannot even use your CDN, we have to host
everything internally. All that pulling inside and having to recreate that layer was a little
costly. We did it, I think it was worth it, but it would be good to think about that kind
of people as well. Because it has an excellent enterprise footprint. YUI is enterprise DNA,
it knows just let others explore it in those ways. That's just a thought.
Audience member 4: We had to bring everything in house as well. One of the big hurdles for
us was actually the combo loader. Open sourcing YUI's combo loader would actually be really
helpful. We wrote our own in Java and actually changed it so that it was shorter URLs as
well, just to make it faster.
But just some of that infrastructure piece, open sourcing that would probably help a lot.
We did build a framework on top of YUI as well and used that to build our applications.
Jenny: Where do you work?
Audience member 4: IXL Learning.
Jenny: Yeah, I think I'm most proud of YUI as fulfilling the niche of being the framework
developers' framework. Where is Eugene? Eugene's working on... Do you want to talk about it?
Andrew: Yes Eugene, talk about it.
[laughter]
Eugene Kashida: Yeah, I don't know if this is what you're talking about but actually
Ryan has an open sourced combo handler that you could probably use. Okay.
Daniel: Yeah, okay. So yeah, our Grove combo handler on GitHub, it's under combo-handler
on NPM. I just recently upped the test coverage significantly and it's very configurable.
Runs in Express server, it's pretty cool. Any questions, come find me. I'm Daniel.
Eugene: But the combo handler that Yahoo uses today, I'm actually not sure if it's an open
source plugin. Oh, it's not? Okay.
I've been working basically to solve the problem of having shorter combo URLs because we've
been following the best practices of making everything more modular and that's caused
an explosion in the number of modules that we have. As a result of that we have these
really long combo URLs that, you know, if you used the app module you get I think three
or four combo URLs.
My work recently has been in trying to solve that problem of making these URLs shorter
and as a result of that we're kind of moving over toů Like the architecture, we're changing
the architecture to something where we use a plugin called ESI, which I believe is open
sourced.
I guess when we actually prove that it'll work in production I can talk more about that,
but in the interim I think you should take a look at rgrove's combo handler.
Jenny: The idea is with the proliferation of modules you end up with perhaps three or
four really lengthy URLs per page, just as an 80 per cent use case. If we can get the
syntax of the URL shorter we might get a 50 per cent benefit on the HTTP request side,
which is a huge performance benefit.
Ryan: Hi. I'm rgrove, you may have heard of my combo handler.
Audience member 4: We actually looked at it for inspiration.
Ryan: I wanted to point out something that is something I've come to feel, and I don't
know if this is going to be a popular opinion, but I think that a combo handler is not the
end state that you should be going for for distributing your modules.
I think a combo handler is a nice stopgap, it's a nice convenient thing that helps you
load groups of modules efficiently while being lazy, but really I think a better solution
is to think about your modules in terms of bundles and think about how you can statically
bundle those modules at build time as a build step before you deploy and then rely on combo
handling for those dynamic cases that you can't reason about beforehand. So if you are
going to lazily load something then combo handle that, but don't just combo handle your
initial upfront payload that you always know is going to be the same. That's where you
get these really long combo handler URLs.
There is a place for combo handling and I think it's very useful, but I'd like to see
us as a community get away from using it as our one and only loading mechanism.
Audience member 4: I guess what I'd like to see is just more open sourcing of that kind
of thing. Specifically I was saying that the combo handler that the YUI CDN uses, it would
be nice to see that as an open source project instead of having to roll our own using Ryan's
as an example, and then we built our own on top of that and tweaked it a little bit for
our...
But then if we're talking about doing these rollups and stuff like that, getting some
of that into the open source community I think would be a really good idea. Because I feel
the same way and I'm working on infrastructure for our company but it takes a while.
Ryan: Yeah, I can't speak to Yahoo's actual combo handler. Even when I was working at
Yahoo I had nothing to do with it. But I think that if it were open sourced you'd find out
that there's nothing really special going on there beyond what you've written and what
I've written and what I'm sure 15 other people in this room have written. It's a fairly simple
concept but it's one that I feel we get stuck on too often.
So I wouldn't want to see that be a stumbling block for people using modules if they're
worried about creating these long combo handler URLs and like oh crap, I can't host YUI because
then I have to write my own combo handler. That really sucks and I agree we need better
tooling around creating static bundles and building YUI and self-hosting and things like
that. I think some of that's coming.
Caridy is reaching for the mic.
Caridy: Yeah, I could not agree more with Ryan. It is all about convenience. To be able
to provide tools that will produce what your application and your specific application
needs we need to be able to analyze whatever is there for the application, what are the
capabilities of the application, what are the modules you are using. That will enable
us to create some sort of tool that will go and produce this piece of code that you can
just include in your pages without having to get into the loader to get the page ready.
Loader is expensive, computations are expensive. We have been looking into expanding the loader
metadata. It is freaking expensive as well, because now you have a massive amount of metadata
that you have to load.
All those problems we are looking at it, but it seems that the solution will be around
those lines, being able to analyze the application, the structure of your application during the
build process, using this loader information to produce what we call rollup. It's just
a file that you load in your application.
On the Mojito side of things, the guys from Search did the Shaker implementation which
is doing something similar: analyzing the application and producing these balanced files
that have around the same size and you load them in parallel, the kind of things you can
do today. But we want to take that to the next level and be able to really produce what
you need per application basics and then using the loader just for the pieces that are remaining,
pieces that you want to load on demand.
Daniel: I just wanted to, in the same vein that Ryan was talking about static bundling,
using the word bundle suspiciously, were you planning on open sourcing the gist you showed
me a few months ago?
Ryan: Alright, so I work for SmugMug and we had this problem as well. We have our own
custom PHP combo handler which was serving all our JavaScript, and a while back we launched
a brand new version of SmugMug that had a lot of YUI 3 in it. Relying on that combo
handler meant we were having page loads where there'd be like 10 combo handled URLs that
were hitting their max URL length all loading before we could render stuff onto the page,
which really sucked.
So I wrote this Grunt task that essentially used YUI Loader to figure out our dependencies
at build time and compiled together static bundles that we then just posted on our CDN.
It's just a single static URL. It turned out to be really simple and I would like to open
source it, yes. I haven't had time yet, but that would be something that I think would
be nice to do.
And I think there are probably similar things that the YUI team could actually do as part
of YUI and as part of what I think is an initiative to move more towards embracing things like
Grunt and embracing other types of package systems for distribution and things like that.
So yeah, I'd be happy to help with that.
Audience member 5: I believe that we have a lot of problems with YUI, I think, related
with bundles and loaders and a lot of other things. But I work for Yahoo Mail and a very
big problem that we have every time that we hire someone is that this new hire needs to
learn YUI.
The documentation is not great I think. Look for Ember and what Ember did in this last
year, just related with the documentation, not with the application itself. I really
think that if we improve a little bit the documentation to, I don't know, give more
examples that the people can interact in, learn fast with the documentation, it would
be great and would help everybody to adopt YUI, and will help us to train new hires inside
Yahoo.
Andrew: Yeah, I can speak a little bit to that. One of the projects I'm working on this
coming quarter is a way to help people get basically on track. If you're a complete newbie
to YUI you'd go through a specific track where you go... Basically all the documentation
that we have, it'll be in sort of a path that you go onto, like a quest or something like
that. All the documentation, all the videos, everything will be synced in with that level
of learning.
Then once you've reached intermediate mode then you start on the intermediate track.
It's almost kind of like a Khan Academy kind of thing where you can basically work your
way through, and when you get done it's almost like you've got an achievement.
Another thing I really wanted to bring up today is the possibility of open sourcing
this idea of documentation. Right now we have documentation you can contribute to, but also
coming up with a way to open source the idea of new tutorials or new components, things
like that. That's one of the efforts I'm working this quarter to find a way to not only create
this new documentation but find ways for other people to build that as well.
Tony Pipkin: One thing, just to speak on the fact that the documentation, it's all open
source, so if anybody has any extra examples or anything like that that they want to add
to it, write them, issue a pull request.
Caridy: About what you mentioned. No matter how much documentation we put out there it's
never going to be enough, especially for people who create frameworks like Mail, like Wells
Fargo, like Flickr. It doesn't matter how much information we put out there because
at the end of the day those frameworks are built on top of YUI and they do their own
thing. Sometimes good things, sometimes not what we recommend, and so on. So it's going
to be difficult.
We want to continue focus on creating building blocks and documenting how to use those building
blocks. But how you put them together and how you create these very complex structures,
it's going to be difficult for us to create documentation for that. It's going to be difficult.
Audience member 5: I believe there are two different scenarios, right. One scenario is
people building Modown and other frameworks inside Yahoo that use the documentation. For
these people I really think the documentation right now is good, because the documentation
right now basically describes the interface for objects and these kind of things.
But for people come outside that to have their first experience with YUI, there is another
step. There is another scenario. One thing is I believe that almost everybody here has
some kind of experience in YUI and can navigate through the documentation and strike something
useful. But when you get someone that came from jQuery, MooTools, outside of YUI world,
I don't think that these people feel comfortable navigating the documentation of YUI and learning
about different work.
I believe that yeah, I can agree with you for people that are building frameworks and
go very deep inside YUI, the documentation works today and it doesn't matter how much
documentation you put there, it would not be enough. You would need to go inside the
code and read the code and see how things are coupled and they are working. But for
people outside, I really think that we need to improve.
Audience member 6: I'm going to say one thing. I don't think it's a matter of documentation.
I mean I've been trying a lot of libraries and I think the problem is that you have to
just know JavaScript for whatever you're using. I mean I can give a talk about the answer
I get when I ask oh, you know jQuery, so what's the dollar? I think that the problem is not
the documentation, I think the problem is teaching the people to write good JavaScript
in the first place.
Then documentation, I think there is no better documentation actually than the YUI one. You
have examples. Even the code that these guys release on GitHub has a lot of documentation.
So I think maybe we're hiring the wrong person. I don't know. Just saying.
I think that, you know, I'm tired of seeing this conference about oh, in this company
we created this client side rendering, like yeah, we had it two years ago. Oh, we're using
this new amazing asynchronous loading, oh, YUI had this five years ago. It's like what's
the problem here? It's not that we don't have documentation, just people like to use other
popular or fancy things. That's my opinion. And again, I think the documentation is, I
don't know... My English is pretty bad.
[laughter]
When I read the documentation I actually feel a really comfortable feeling when I read the
YUI documentation. So I don't know, that's my opinion and I think that whoever doesn't
understand the documentation of YUI can learn first the good parts of JavaScript.
Caridy: From the pragmatic point of view on this, we are moving into ES6 modules. Once
we get there modules are going to be standard across the board, and libraries will not be
that different. So hopefully we can get there soon. That's going to help as well. It will
not be that different to use another framework in terms of units of code that you write,
even though the API of each different framework and library will be different, but you just
need JavaScript for that.
Clarence Leung: I'm going to take off my YUI hat for a moment. I came from a jQuery background
before I joined the YUI team, and I think you have a really good point there. There
are some parts of the YUI documentation that can be much improved. For example, I learned
how to use Y.io from JS Rosetta Stone because I couldn't read the I/O documentation.
But speaking along with that, as someone who's working with people that are new to YUI, what
are some of the problems that they're having? What would they prefer to have? Would they
rather have interactive tutorials like the ones in Codecademy for instance? Or do you
have any specific things that these people that are new to YUI are looking for?
Evan Goer: Yeah, I agree that we do have a documentation problem. I agree with the gentleman
from Mail who mentioned this. And he pinpointed the problem: the problem is the YUI documentation
does a really good job of catering to people who already are pretty solid with YUI.
If I want to look up an API method, the API documentation coverage is pretty good and
I can read that and I can click in and see the source and drill down further. Or if I
want to learn about how Y.History works I know how to find that, I know how to go to
the user guide for that and I can read up on that. It's pretty complicated, but there's
a decent documentation page there, there are good examples.
The problem is that this doesn't address the situation of people who are experienced developers
who have experience with other JavaScript libraries and other frameworks and who are
coming into YUI for the first time. If you go to the page that displays all of the user
guides, it's basically flat. I mean you see there's tons and tons of developer guides
and you have no idea where to start, what path should I take through that to actually
learn the system given that I'm a smart person, I know JavaScript, but I don't know the toolkit,
I don't know the library.
I think YUI, the individual pieces of the documentation are pretty good and are good
for people who have medium to high levels of experience with YUI, but they don't do
a good job of bringing someone who's a novice into the medium skill area, and that's the
problem that people are running into when they try to bring YUI into a company or hire
new people who don't know YUI.
Audience member: Can you recommend a good book for those people?
[laughter]
Jenny: Hey Andrew, do you want to spend a minute talking about your ideas in that area?
Andrew: Yeah it's funny you should mention this because like I said a few minutes ago,
this idea of having these paths where you start off as a complete novice and it takes
you all the way to the point where you become intermediate and then you work your way to
becoming expert, that's something I'm currently working on this quarter.
You're going to see things where you can basically know, no matter where you go in the documentation,
where to go next. Because there always seems to be this cliff. You'll read a tutorial and
then you'll wonder what am I going to do now? Or you look at a YouTube video and you wonder,
okay, I've got that, now what's next?
Part of what I'm working on this quarter is to give you that what's next so you can continue
a path from beginning to end. When you get to the end you know now I'm intermediate,
now I'm expert, now I'm totally amazing. That's what I'm working on now. I'll be craving your
feedback on this, so I'll probably be giving out little snippets here and there saying
here, check this out, does this work for you.
It's a good sign that you're talking about this because this is definitely something
that's near and dear to my heart. Not only do I want to create this but I'm actually
going to open source that as well so we can all contribute to it.
Audience member 7: It's sort of funny you should say that, because I was going to rephrase
what he said with an analogy of it which I had just given somebody which is that we have...
If you're like a purple belt in YUI, there's a progression to get to brown and black. And
if you're a white belt you can get to yellow, but there's nothing in between. There's no
blue or the other colors in between that I don't know about because I don't actually
do that.
[laughter]
Orange, sure. Orange. Anyway, that's what it seems like, that's where the big miss is.
It sounds like you're already working on that.
Andrew: Yeah, and again this is near and dear to my heart. In addition to building this
you've seen things like HTML5 Rocks where people create tutorials and stuff and then
that goes in the repo and then it gets published. Imagine something like a scenario like that
for YUI where you've come across something, there's some new feature, and you spend the
time to write an article or tutorial. You'll be able to cement that and other people can
share it.
Audience member 8: As an experienced developer coming into YUI out of Java, ActionScript,
Flex, things like that, I'm amazed that there don't seem to be the tool supports and the
IDEs that allow me to just peruse and navigate the code. I mean, for me the most effective
documentation is the ability to be able to drill in and have code complete. If I have
that then I have a framework that I can go and I can look at documentation and I can
drill into things and I can go on from there.
Eclipse plugins, choose the IDE of your choice, but regardless, some way of navigating the
code base in a way that doesn't sit there and leave me hanging with a bunch of... It's
from this anonymous inner class business that just seems to throw most of these IDEs into
a tizzy and makes it very difficult for me to just explore and find things that work.
Oh, I would write one for you in a heartbeat.
Jenny: Right, and to your point we had...
Audience member 9: Yeah, I think having an IDE that you could actually explore the APIs
would be great, but in the absence of that I think more examples you could have because
then it almost provides you the same thing. You can walk the object tree and say oh, this
comes after this, comes after this, etcetera.
Audience member 8: The problem that I have with that is there's the world of toy problems.
And toy problems are great. But there are many times when I'm putting together something
very large, very complex, that seeing how things were done in other applications really
helps.
I once had to write a memory manager to handle a million point dataset and it's never going
to be a toy problem. You look at other things that are kind of like that. The ability to
drill down and go oh that's how they're handling their memory, that becomes a really important
thing that never comes up but it's there in the code and you know because the code works
that you have an existence proof and you can kind of figure your way through it.
Audience member 9: Yeah I definitely agree, but as far as the uninitiated person, when
they kind of dive into YUI and they say I just want to do X or Y etcetera...
Audience member 8: Sure, and I don't deny that. I think that tutorials are fantastic
and I like to start with tutorials. But once I've gotten past the hello world part of the
game where I'm bringing up, okay, I can do that, I can make a window, I can move the
window around and I can edit text, yay, I can speak the language.
But we have a 120,000 line program that does auditable financial records. You're never
going to find tutorials that even come close to that. So again, being able to just see
how to structure the code, how to involve... What we're talking about is reducing the cognitive
load, the cognitive stress on the developer. They have so much attention, they have so
much ability to be able to focus on particular things.
If you're trying to figure out what the next method in a class is, you are wasting your
time. That should be presented, it should be straightforward. That part of the development
process, at this point in software development, should be utterly transparent to us. It's
a well solved problem. Visual Studio has it, WebStorm has it, Eclipse has it. We can go
on and on.
I don't want to spend my budget of concentration trying to figure out what a method call is,
what a property is. I want to be able to have that there immediately.
Audience member 5: I think that Visual Studio do amazing work on this, showing the documentation
and the paths, everything. Probably the best IDE we have these days, not for JavaScript
but overall.
Audience member 8: I mean I could make a case that I think Eclipse and Java are just an
amazing piece of work.
Audience member 5: I follow the development of Windows 8 inside Yahoo, and I can say to
you that every time that the guys import something outside, like there was not a WinRT JavaScript
file, I believe that the Visual Studio imported all the documentation and everything for them.
I believe Visual Studio has the capacity to import the documentation and look for your
JavaScript code and debug these kinds of things.
Audience member 8: And it'll unwrap lambda classes?
Audience member 5: I cannot say. But it is one path to explore.
Eric: One suggestion around tooling and large application code bases, why not use TypeScript?
Microsoft is trying to solve this problem in a non-invasive way, forward looking in
terms of ES6-style features, all these sorts of documentation are tooling autocompleting
bells and whistles that you're looking for. That seems like the answer to me, kind of
a no brainer especially if you have a large team and a large code base.
Andrew: Do we have any more questions or comments?
Jenny: Just to recap so far. We had gallery, documentation, combo handler, SSL...
Andrew: I'm getting my exercise here.
Jenny: Learnability.
Audience member 10: I just had an idea. In terms of community and what people want, how
about implementing something... Like I know there's a feedback thing in Yahoo Mail and
it's like an outsourced, I don't know what their solution is, but people can submit their
issues and vote up issues. That would be a good way to see what things people want to
see in the future of YUI.
Jenny: Yeah, to continue this conversation after this session, the two places that I'd
like to see us congregating on an ongoing basis would be the yui-contrib mailing list.
That's a great place to throw out nascent ideas, get feedback on things that are more
higher level.
And then as Andrew is mentioning, the GitHub system of filing bugs there, issuing pull
requests there, is a great place to take some of those higher level ideas, turn them into
tangible improvements to the project. We have numerous examples of bugs and pull requests
that are actually ongoing conversations where the idea gets fine-tuned and feedback is received,
and then at some point successfully merged back into the project.
Those vehicles are a really great place to continue the conversation. If you see a bug
that is also a pain point for you, go ahead and comment on it. Like I said, the squeakier
wheels get the attention. I think those forms are already in place and ready for you to
participate in after this session.
Anyone else have any final thoughts or comments or pain points?
Cool. Well as always we love hearing this feedback. The pain points kind of define where
the road map should go, so we're keenly aware of the points that now I have recapped. We
will continue those conversations and keep track of them and revisit them quarter after
quarter and then come back next year and talk about the improvements we've made in these
areas.
With that, I think we can bring this session to a close. It's kind of nice. It feels like
we just had an in-person hang out. Do you guys agree a little bit? Yeah, kind of cool
to have everyone in the same room.
Mark's got something back there.
Mark: On those hang out videos on YUI Library, can you put descriptions of what they're about?
Jenny: Alright, we're getting a request for descriptions on the hang out videos. So you
want a summary of what was discussed for every video?
Mark: Yeah, what they're about. I don't know if they're worth watching.
Jenny: Okay. I thought we were capturing that on the wiki. Are you saying like in the video
description itself?
Mark: Yeah, yeah.
Jenny: Alright, good one. See, little pain points like that is really good feedback to
get.
Andrew: I just want to put in a plug for that, for the open roundtables. One of the things
that I'm really keenly interested in is this coming year I want to get more of you guys
in the roundtables. Right now I feel like I'm just talking to the same people over again,
so if you have anything you want to share, any code you want to share, any new ideas,
come to the roundtables. We have the wiki page up where you can post topics, and I'm
more than happy to help out rearrange a good time for you to come on the roundtable and
talk about your cool stuff.
Jenny: And it can be an open forum, kind of like this but on an ongoing virtual basis.
If you need a code review, or you've got an idea that you want to vet and get some feedback
on, those weekly discussions are a really good place to get real-time feedback, in addition
to complimenting all the virtual online conversations that are also happening.