I fixed #12690 for 1.8.3 but there's nothing in place to prevent a regression. Seems like it should be doable with the appropriate grep options in a grunt build step.

the #jQuery channel is one of the most active on freenode. over time, there is a lot of unstructured knowledge within the day to day dialog.

there are a number of open source packages to do this kind of stuff. we may want to look here for inspiration:
http://www.irc-junkie.org/2010-07-14/irc-statistics-software-comparison/

some information that would be nice to display on a dashboard could be:

• activity correlated by releases
• sentiment analysis (see #13)
• most/least discussed API portions, bugs
• parse the IRC logs for bot answers (and compile a list of entries for use by the new bot).

Fixed toolbars and/or transitions issues:
https://github.com/jquery/jquery-mobile/issues?labels=Dev+summit&milestone=16&page=1&sort=created&state=open

Additionally we can work on issues about button clicks misfiring: https://github.com/jquery/jquery-mobile/issues?labels=Click+target&milestone=&page=1&sort=created&state=open

Right now it closes "invalid" but it would be better to close "inactive" or some such.

build a splunk app/input to ingest google+ api (or find one that already exists)

google+ search endpoint docs:
https://developers.google.com/+/api/latest/activities/search

this could be used by:
- sentiment analysis #13
- info-graphic #10

build dashboard that reports on the data collected by profiler input (see #16)

make the results generated by the plugins dashboard (#21) avalible to the plugins site.

we can schedule a CSV or JSON export of the data - or use the proxy/API with a greater amount of effort.

depends on #21

https://github.com/jquery/2012-dev-summit/wiki/Table-10:-UI-Widgets
http://wiki.jqueryui.com/w/page/38666403/Menubar

The "new bug" page on the core bug tracker needs several improvements:

• the giant red banner at the top has links to the deprecated docs site, those need to be updated or removed.
• the giant red banner has too much text and too many options. Needs to be dramatically simplified.
• It should warn, but not prevent submission, when an external link like jsbin or jsfiddle is not present
• it should require an email address for the submission, but provide an option to make that email address private, and only used for communication
• it should do a rudimentary duplicate search before submission, similar to what stackoverflow.com does when attempting to submit a question

• browser testing
  • test open bugs in multiple browsers and discover which browsers the bug is in... add keywords mentioning which browser this effects
• fully reduce test cases
  • make sure bugs expose as close to core as possible the root cause of the bug
• dig into jQuery codebase to find internal location of bugs
  • leave comments on tickets about where the problem lies

report on our usage of browserstack.

there is an existing dashboard that needs some attention since the testswarm rewrite has changed the rules a little.

https://github.com/jquery/2012-dev-summit/wiki/Table-10:-UI-Widgets
http://wiki.jqueryui.com/w/page/12138056/Selectmenu

• this is done when this report is empty: http://bugs.jquery.com/query?status=new&report=505&order=priority
• triage all "new" bugs, get them to "pending" or "open" or "duplicate" state.
  • to get to "duplicate", error needs to describe exact symptoms of another issue.
  • to get to "open" state, the reproducible error should be demonstrable on jsfiddle or jsbin. If one is not provided, we attempt to recreate the error with the information provided.
  • to get to "pending" state, the error clearly needs more information to be demonstrable, and we are unable to repro given the provided info.

A lot of the existing articles have some leftover metadata that is irrelevant to the current state of affairs, including things like an editrequired field to track an article's suitabiliity for publishing (um, hello, that's what issues are for....) and an attribution field that isn't displayed anywhere. We should remove this cruft.

For articles where "jQuery Fundamentals" is listed as the attribution, we should grandfather in that information using the convention we settle on in #44.

https://github.com/jquery/2012-dev-summit/wiki/Table-10:-UI-Widgets
http://wiki.jqueryui.com/w/page/12137778/Datepicker

• This is done when this report is empty: http://bugs.jquery.com/query?keywords=~needsdocs&report=406&order=priority
• look and see if any of these tickets already have updated docs on api.jquery.com and in the api.jquery.com issue tracker, if so, remove needsdocs tag
• all remaining tickets need to have a ticket created in the http://github.com/jquery/api.jquery.com issue tracker, and then the "needsdocs" tag removed from core bug tracker

not only would it be nice to publish the data jQuery collects; it would be great to allow users to share their data with us.

this effort involves building a Splunk input that accepts HTTP posts from a profiler running in a client.

the profiler would be an instrumentation script that duck-punches the jQuery lib, and reports back usage. we would want to throttle calls home, and also report on the environment (browser, resolution). the events would be API calls, stack traces/errors, and performance.

A crude version of this was working in the nanoc build using the github metadata, where we'd hit the github API for whoever was specified in that metadata, an obviously subpar solution. We should read the file's git history and display the full list of contributors who've actually worked on the file (ranked?).

Not sure what to display, exactly, however, for contributors, as I don't think we want to be hitting the GitHub API during build anymore.

We may still have to grandfather in the "original contributors" using some metadata, for people who wrote articles in other sources and donated to the learn site, but didn't make the initial commit contribution themselves (as in the case of the original jQuery Fundamentals content)

Looking up contributor history might be useful for other sites besides learn, so this might be something we could incorporate into grunt-jquery-content perhaps.

open up the jQuery data to the outside world via Splunk API.

OOOR, at the very least, we can build a script that will extract output from saved searches, and make available a CSV file on a web server.

if we are to expose splunkd, we will need to (this may be an ambitious goal, but could be interesting):

• cache responses
• for authentication, share a user/password, expose tokens, or slipstream credentials
  • if we put a form online that hands out tokens, we could add a captcha
• white list endpoints
  • filter parameters
  • filter search terms (only allow certain indexes, and search string length)
• rate limit per IP or token

http://swarm.jquery.org/result/325481

The docs tables should be near each other in case there are cross-table questions.

Each article's footer should include a link to the same article in the learn.jquery.com master on GitHub. Though the link obviously won't work for new articles in development, it will be just fine in production on learn.jquery.com, which is where it counts here.

on a single HTML page, we will build some JS that will take the data from #11, and render it to produce the desing in #10. simple!

lets try to keep things modular, so we can have more than one developer working on a different area of the graphic in parallel.

this will likely reside on the jquery.com domain, but development can be done on a local file, without a web server.

Features like jQuery.browser are being removed from jQuery 1.9 to clean up the API, reduce the size of the library, and reflect the best practices that we preach. To ensure that we don't break too much code, they will be available in a jquery-compat.js plugin that can be included alongside jQuery 1.9 or 2.0.

I don't think there's a whole lot of actual coding to be done here, but it does cross a bunch of areas so I've marked it as something that could involve all four core tables. You could even say, 😏 ➡️ 😎, this problem requires quad-core processing. Here are the tasks I can see at the moment:

• Identify the existing Trac tickets related to removing these features, or create new ones if they don't already exist.
• Ensure that the API docs are clear that these were deprecated as of some previous version (many as of 1.8) and are removed in 1.9 but can still be found in the compat plugin. Some banner or background should make it clear so people won't accidentally use these. The current docs aren't in-your-face enough IMO.
• Move the API or functionality from the core code and tests to the plugin. Each API call should go in its own file so that it is possible to include them separately. Unit tests can be done only on the combined file if that's easier.
• Create a build file to create and lint the combined file but perhaps also minify the individual files so they can be used without the entire plugin.

I was thinking it would be useful if the uncompressed "development" version of the plugin would generate console messages to warn that deprecated/removed functions were being used. Uglify has a feature to allow these to be removed as dead code in the minified builds. It might be possible to even use the compat plugin as a migration tool with <1.9 code to let you know that something was using features that should be avoided or rewritten.

NOTE: Not all deprecated APIs are being removed; for example .live() is staying although it is deprecated. Also note that not all removed functionality has to be supported by the compat plugin if it turns out to be too difficult to do--let's discuss as we come to those situations.

Team Leads:

Please verify that your table's (and any other tables you may be strongly involved with the work of) requirements are accurate and reasonably thorough. ASAP :)

create (scheduled) saved searches to gather data required to render the info-graphic.

this ticket should contain descriptions of the searches we will need.

we need a script which will extract the output of the saved searches in a jsonp format (see #9), and make it available within a web accessible directory.

to keep interests contained, it may be best to have this script reside on the same server/location as the other assets required for the info-graphic site/page, and not on the actual index server (which may not have a http damon).

this script will likely be python, but the jQuery folks would prefer if it was JS/node.

http://wiki.jqueryui.com/Pull-Requests

Perhaps other wiki pages need updating as well, to reflect our current processes

• if they are fixed now, resolve as fixed and add version it was fixed in as milestone.

• develop failing unit tests based on open and assigned bug reports
• work with core bugs team to fix the bug together and test in browsers

https://github.com/jquery/2012-dev-summit/wiki/Table-10:-UI-Widgets
http://wiki.jqueryui.com/w/page/12138092/Timepicker

• This is done when all currently pending bugs truly can not be investigated further without feedback from the OP.
• look through current "pending" bugs: http://bugs.jquery.com/report/303 , and see if any can be investigated further and rescued to an "open" status without needing more info from OP, and rescue those back from a trac-o-bot fate.
• if a ticket can be rescued, attach a valid jsfiddle or jsbin and mark the ticket as open.

• This is done when all tickets in http://bugs.jquery.com/report/500 that are newer than 3 months old have been gone through.
• See if any can be investigated further and rescued to an "open" status without needing more info from OP, and rescue those back from a trac-o-bot fate.

build saved searches which report plugin usage analytics:

some possible metrics could include:

• number of downloads by app
• trending plugins
• users who viewed/downloaded plugin X also viewed/downloaded plugin A, B, C
• the likelihood of users to view a plugin page and continue with download

build a dashboard to track the sentiment of the community.

the main goal will be to assess the mood among the developers who use and build jQuery. how many times does the word "sucks" and "jQuery" appear in social feeds?

use this issue to track the dashboard panels to be built.

at the top of this dashboard, a single result will combine a weighted result ba based on all panels possible. we will plot this score over time, and correlate with code quality, bug latency, and participation metrics.

this could feed off of many inputs. such as. twitter, irc, forums, trac, issues, google+, git participation, ...

WHY:
its important to keep the pulse of the community to track how well jQuery is doing. happy community means growing community.

Should we use GitHub issues to track the to-dos on a per-table basis? Even if the issues are just links to issues in other repos, I think it is a neater way of tracking what we want to have done and what's been done than just constantly editing a wiki.

On the other hand, it adds a bit more overhead.

Would like to decide in the next few hours so we can start putting todos in here or the wiki, as I'm about to start onboarding the attendees.

Add a slide panel widget that opens a panel to the left/right/top/bottom of the screen and either slides over the page (like a menu) or pushes the page over/down/up (like Facebook's menu)
jquery-archive/jquery-mobile#5163

Add a few more grid types that have non-equal widths - 25/75, 75/25, 25/50/25, 33/66
jquery-archive/jquery-mobile#5164

Tile layout - multiple list items arranged in a floated grid arrangement for photos, products, etc. - fixed width vs. fluid width - media queries to adjust the number per line
jquery-archive/jquery-mobile#4956

Key/value pair list type
jquery-archive/jquery-mobile#2230

Responsive option for grid modules - Add an option class like ui-responsive to a parent div to make the child grids stack below a certain breakpoint
jquery-archive/jquery-mobile#4955

Make tabular data tables responsive by hiding and showing columns based on screen width and adding a chooser to let users control what columns they are viewing.
jquery-archive/jquery-mobile#5093

unfortunately, we dont have an unlimited amount of disk space. we need to limit the data stored on disk by Splunk.

take all data sources as identified within #9, design a LIVING info-graphic that represents the data. in a cool way.

the goal is to then take this design, and render it dynamically using JS/HTML/CSS. Hence the LIVING part.

The home page has been placeholder content - it needs to be laid out with some information about the site's mission, links to other resources inside and outside of the jquery.com network of sites, information about recently added and updated articles, and some graphic appeal.

build a simple form that allows a jQuery team member (or even any member of the public) to submit their IRC nick, and an email address. we will then create an alert in Splunk upon mention of the nick on any of the jQuery channels.

to prevent spam, we would need to build a simple authorization:

1. user fills in form
2. send an ajax GET request to register.html?nick=bob&email=[email protected]&guid=xyz
3. we send confirmation email, with link to confirm.html?guid=xyz
4. when a user hits the confirm page (or maybe via batch script) we look for corresponding request with guid to register.html. if it exists, create an alert.

to prevent abuse, need a captcha, and limit to only one alert per email address.

One thing that perished in my abolition of nanoc from the learn site was the functionality of the order.yml file, which is supposed to define the order (using the "menu_order" column in the WordPress posts table), that articles are presented in the site, as well as preventing articles from being "published" when they shouldn't be (only slugs in the file should be published).

I created this ordered pages plugin for wintersmith to do this, but it isn't quite functional yet. We should get this working, or find a better solution than this plugin.

• This is done when these reports are empty: http://bugs.jquery.com/report/400 and http://bugs.jquery.com/report/404
  • make sure all bugs have priority: http://bugs.jquery.com/report/400
  • make sure all bugs have component: http://bugs.jquery.com/report/404

• this is done when all the open bugs are not duplicates
• error needs to describe exact symptoms of another issue.

is what we're shooting for here

grunt-jquery-content supports syntax highlighting using node-syntaxhighlighter , however it's not currently properly highlighting javascript (and css) snippets inside of HTML pages. grunt-jquery-content is currently using 0.7.x of node-syntaxhlighlighter, which was updated in 0.8.x to "support" hybrid syntax highlighting, but I just dropped it in locally and it also is not properly highlighting hybrid codeblocks, so it's not as simple as just updating to the latest version. If we can't get it to work properly with node-syntaxhighlighter, we might want to try @thlorenz's pygmentsjs, which unlike our own node-pygmentize tries to be a lot more efficient by not spinning up a new process for every single code block (which was very slow, and why we switched to node-syntaxhilighter in the first place!)

In any case, we should get this straightened out ASAP as it was a rough spot for me when I was working through the syntax highlighting a few months ago, and was one of the first things pointed out after the release of the new jQuery UI API site by @nicinabox.

Most of the articles in the site still are using the leftover convention from our custom nanoc build, which was to use <javascript caption="foo">, etc. In the interest of not-reinventing-the-wheel and facilitating contribution, we've decided to switch to gfm, which is supported by wintersmith. In the meanwhile, code examples using the old format are not working.

track the trac.

report on:

• ticket volume
• percent of tickets by end result
• ticket latency (by assignee)
• performance metrics (page load times)
• proactively identify and triage tickets
  • it would be very interesting to proactively identify tickets that may be support cases (rather than legitimate bug). we could also attempt to find dupes. this would provide triage with a quick way to weed out and redirect these cases.
• user participation
  • top contributors (submitters, triage'ers, commenters, resolvers)
  • bounces (how many users submit a bug never to return)
    • who are the top members who lead to bounced users (if a member comments on a ticket, and the submitter does not return... what did he say that was so bad?)

This was working in nanoc, but the functionality needs to be re-implemented using some simple WordPress template stuff and the menu_order metadata, once it's available (#38)

https://github.com/jquery/2012-dev-summit/wiki/Table-10:-UI-Widgets
http://wiki.jqueryui.com/w/page/12137996/Mask

Suggested improvements:

• introduce reserved characters to wrap user-defined placeholder strings
• introduce ability to escape reserved characters (default placeholders, the pair of characters introduced by the previous task, and the optional segment delimiter)
• disallow use of multiple un-escaped optional segment delimiters (or add support for multiple optional segments)