diff --git a/.github/workflows/markdownlint.yml b/.github/workflows/markdownlint.yml
new file mode 100644
index 00000000..9dc6bec9
--- /dev/null
+++ b/.github/workflows/markdownlint.yml
@@ -0,0 +1,31 @@
+---
+name: MarkdownLint
+
+on:
+  push:
+  pull_request:
+    branches: [master, main]
+
+#env:
+
+concurrency:
+  # https://docs.github.com/en/actions/using-jobs/using-concurrency
+  group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}
+  cancel-in-progress: true
+
+jobs:
+
+  build:
+    name: markdownlint
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout Code
+        uses: actions/checkout@v3
+
+      - name: markdownlint-cli
+        uses: nosborn/github-action-markdown-cli@v3
+        with:
+          files: .
+          config_file: ".markdownlint.yaml"
+          #ignore_files: "examples/ignore/*"
+          #rules: "examples/rules/custom.js"
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
new file mode 100644
index 00000000..d252e2a9
--- /dev/null
+++ b/.markdownlint.yaml
@@ -0,0 +1,8 @@
+
+# disable line-length
+# (we have a lot of long lines right now, remove this after a cleanup)
+MD013: false
+
+# disable no-emphasis-as-heading
+# (there's a lot of these, clean them up and remove this)
+MD036: false
diff --git a/Dockerfile b/Dockerfile
index dbc56e68..287494f8 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM ruby:2.5
+FROM ruby:3.1
 MAINTAINER mrafayaleem@gmail.com
 
 RUN apt-get clean \
@@ -13,7 +13,7 @@ RUN apt-get update
 
 RUN apt-get install -y \
     nodejs \
-    python-pygments
+    python3-pygments
 
 RUN apt-get clean \
   && rm -rf /var/lib/apt/lists/
diff --git a/Gemfile b/Gemfile
index d2e1a452..26cf58d7 100644
--- a/Gemfile
+++ b/Gemfile
@@ -2,3 +2,10 @@ source "https://rubygems.org"
 
 gem 'github-pages', group: :jekyll_plugins
 gem 'wdm', '>= 0.1.0' if Gem.win_platform?
+
+gem "webrick", "~> 1.8"
+
+# https://github.com/ffi/ffi/issues/1103
+gem "ffi", "< 1.17.0"
+
+
diff --git a/Gemfile.lock b/Gemfile.lock
index 7b6c4039..6458dc17 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,249 +1,284 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (4.2.11.1)
-      i18n (~> 0.7)
-      minitest (~> 5.1)
-      thread_safe (~> 0.3, >= 0.3.4)
-      tzinfo (~> 1.1)
-    addressable (2.7.0)
-      public_suffix (>= 2.0.2, < 5.0)
+    activesupport (7.2.2.1)
+      base64
+      benchmark (>= 0.3)
+      bigdecimal
+      concurrent-ruby (~> 1.0, >= 1.3.1)
+      connection_pool (>= 2.2.5)
+      drb
+      i18n (>= 1.6, < 2)
+      logger (>= 1.4.2)
+      minitest (>= 5.1)
+      securerandom (>= 0.3)
+      tzinfo (~> 2.0, >= 2.0.5)
+    addressable (2.8.7)
+      public_suffix (>= 2.0.2, < 7.0)
+    base64 (0.2.0)
+    benchmark (0.4.1)
+    bigdecimal (3.2.2)
     coffee-script (2.4.1)
       coffee-script-source
       execjs
-    coffee-script-source (1.11.1)
+    coffee-script-source (1.12.2)
     colorator (1.1.0)
-    commonmarker (0.17.13)
-      ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.5)
-    dnsruby (1.61.3)
-      addressable (~> 2.5)
-    em-websocket (0.5.1)
+    commonmarker (0.23.11)
+    concurrent-ruby (1.3.5)
+    connection_pool (2.5.3)
+    csv (3.3.5)
+    dnsruby (1.72.4)
+      base64 (~> 0.2.0)
+      logger (~> 1.6.5)
+      simpleidn (~> 0.2.1)
+    drb (2.2.3)
+    em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
-      http_parser.rb (~> 0.6.0)
-    ethon (0.12.0)
-      ffi (>= 1.3.0)
+      http_parser.rb (~> 0)
+    ethon (0.16.0)
+      ffi (>= 1.15.0)
     eventmachine (1.2.7)
-    execjs (2.7.0)
-    faraday (0.16.2)
-      multipart-post (>= 1.2, < 3)
-    ffi (1.11.1)
+    execjs (2.10.0)
+    faraday (2.13.4)
+      faraday-net_http (>= 2.0, < 3.5)
+      json
+      logger
+    faraday-net_http (3.4.1)
+      net-http (>= 0.5.0)
+    ffi (1.16.3)
     forwardable-extended (2.6.0)
-    gemoji (3.0.1)
-    github-pages (200)
-      activesupport (= 4.2.11.1)
-      github-pages-health-check (= 1.16.1)
-      jekyll (= 3.8.5)
-      jekyll-avatar (= 0.6.0)
-      jekyll-coffeescript (= 1.1.1)
-      jekyll-commonmark-ghpages (= 0.1.5)
-      jekyll-default-layout (= 0.1.4)
-      jekyll-feed (= 0.11.0)
+    gemoji (4.1.0)
+    github-pages (232)
+      github-pages-health-check (= 1.18.2)
+      jekyll (= 3.10.0)
+      jekyll-avatar (= 0.8.0)
+      jekyll-coffeescript (= 1.2.2)
+      jekyll-commonmark-ghpages (= 0.5.1)
+      jekyll-default-layout (= 0.1.5)
+      jekyll-feed (= 0.17.0)
       jekyll-gist (= 1.5.0)
-      jekyll-github-metadata (= 2.12.1)
-      jekyll-mentions (= 1.4.1)
-      jekyll-optional-front-matter (= 0.3.0)
+      jekyll-github-metadata (= 2.16.1)
+      jekyll-include-cache (= 0.2.1)
+      jekyll-mentions (= 1.6.0)
+      jekyll-optional-front-matter (= 0.3.2)
       jekyll-paginate (= 1.1.0)
-      jekyll-readme-index (= 0.2.0)
-      jekyll-redirect-from (= 0.14.0)
-      jekyll-relative-links (= 0.6.0)
-      jekyll-remote-theme (= 0.4.0)
+      jekyll-readme-index (= 0.3.0)
+      jekyll-redirect-from (= 0.16.0)
+      jekyll-relative-links (= 0.6.1)
+      jekyll-remote-theme (= 0.4.3)
       jekyll-sass-converter (= 1.5.2)
-      jekyll-seo-tag (= 2.5.0)
-      jekyll-sitemap (= 1.2.0)
-      jekyll-swiss (= 0.4.0)
-      jekyll-theme-architect (= 0.1.1)
-      jekyll-theme-cayman (= 0.1.1)
-      jekyll-theme-dinky (= 0.1.1)
-      jekyll-theme-hacker (= 0.1.1)
-      jekyll-theme-leap-day (= 0.1.1)
-      jekyll-theme-merlot (= 0.1.1)
-      jekyll-theme-midnight (= 0.1.1)
-      jekyll-theme-minimal (= 0.1.1)
-      jekyll-theme-modernist (= 0.1.1)
-      jekyll-theme-primer (= 0.5.3)
-      jekyll-theme-slate (= 0.1.1)
-      jekyll-theme-tactile (= 0.1.1)
-      jekyll-theme-time-machine (= 0.1.1)
-      jekyll-titles-from-headings (= 0.5.1)
-      jemoji (= 0.10.2)
-      kramdown (= 1.17.0)
-      liquid (= 4.0.0)
-      listen (= 3.1.5)
+      jekyll-seo-tag (= 2.8.0)
+      jekyll-sitemap (= 1.4.0)
+      jekyll-swiss (= 1.0.0)
+      jekyll-theme-architect (= 0.2.0)
+      jekyll-theme-cayman (= 0.2.0)
+      jekyll-theme-dinky (= 0.2.0)
+      jekyll-theme-hacker (= 0.2.0)
+      jekyll-theme-leap-day (= 0.2.0)
+      jekyll-theme-merlot (= 0.2.0)
+      jekyll-theme-midnight (= 0.2.0)
+      jekyll-theme-minimal (= 0.2.0)
+      jekyll-theme-modernist (= 0.2.0)
+      jekyll-theme-primer (= 0.6.0)
+      jekyll-theme-slate (= 0.2.0)
+      jekyll-theme-tactile (= 0.2.0)
+      jekyll-theme-time-machine (= 0.2.0)
+      jekyll-titles-from-headings (= 0.5.3)
+      jemoji (= 0.13.0)
+      kramdown (= 2.4.0)
+      kramdown-parser-gfm (= 1.1.0)
+      liquid (= 4.0.4)
       mercenary (~> 0.3)
-      minima (= 2.5.0)
-      nokogiri (>= 1.10.4, < 2.0)
-      rouge (= 2.2.1)
+      minima (= 2.5.1)
+      nokogiri (>= 1.16.2, < 2.0)
+      rouge (= 3.30.0)
       terminal-table (~> 1.4)
-    github-pages-health-check (1.16.1)
+      webrick (~> 1.8)
+    github-pages-health-check (1.18.2)
       addressable (~> 2.3)
       dnsruby (~> 1.60)
-      octokit (~> 4.0)
-      public_suffix (~> 3.0)
+      octokit (>= 4, < 8)
+      public_suffix (>= 3.0, < 6.0)
       typhoeus (~> 1.3)
-    html-pipeline (2.12.0)
+    html-pipeline (2.14.3)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    http_parser.rb (0.6.0)
-    i18n (0.9.5)
+    http_parser.rb (0.8.0)
+    i18n (1.14.7)
       concurrent-ruby (~> 1.0)
-    jekyll (3.8.5)
+    jekyll (3.10.0)
       addressable (~> 2.4)
       colorator (~> 1.0)
+      csv (~> 3.0)
       em-websocket (~> 0.5)
-      i18n (~> 0.7)
+      i18n (>= 0.7, < 2)
       jekyll-sass-converter (~> 1.0)
       jekyll-watch (~> 2.0)
-      kramdown (~> 1.14)
+      kramdown (>= 1.17, < 3)
       liquid (~> 4.0)
       mercenary (~> 0.3.3)
       pathutil (~> 0.9)
       rouge (>= 1.7, < 4)
       safe_yaml (~> 1.0)
-    jekyll-avatar (0.6.0)
-      jekyll (~> 3.0)
-    jekyll-coffeescript (1.1.1)
+      webrick (>= 1.0)
+    jekyll-avatar (0.8.0)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-coffeescript (1.2.2)
       coffee-script (~> 2.2)
-      coffee-script-source (~> 1.11.1)
-    jekyll-commonmark (1.3.1)
-      commonmarker (~> 0.14)
+      coffee-script-source (~> 1.12)
+    jekyll-commonmark (1.4.0)
+      commonmarker (~> 0.22)
+    jekyll-commonmark-ghpages (0.5.1)
+      commonmarker (>= 0.23.7, < 1.1.0)
+      jekyll (>= 3.9, < 4.0)
+      jekyll-commonmark (~> 1.4.0)
+      rouge (>= 2.0, < 5.0)
+    jekyll-default-layout (0.1.5)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-feed (0.17.0)
       jekyll (>= 3.7, < 5.0)
-    jekyll-commonmark-ghpages (0.1.5)
-      commonmarker (~> 0.17.6)
-      jekyll-commonmark (~> 1)
-      rouge (~> 2)
-    jekyll-default-layout (0.1.4)
-      jekyll (~> 3.0)
-    jekyll-feed (0.11.0)
-      jekyll (~> 3.3)
     jekyll-gist (1.5.0)
       octokit (~> 4.2)
-    jekyll-github-metadata (2.12.1)
-      jekyll (~> 3.4)
-      octokit (~> 4.0, != 4.4.0)
-    jekyll-mentions (1.4.1)
+    jekyll-github-metadata (2.16.1)
+      jekyll (>= 3.4, < 5.0)
+      octokit (>= 4, < 7, != 4.4.0)
+    jekyll-include-cache (0.2.1)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-mentions (1.6.0)
       html-pipeline (~> 2.3)
-      jekyll (~> 3.0)
-    jekyll-optional-front-matter (0.3.0)
-      jekyll (~> 3.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-optional-front-matter (0.3.2)
+      jekyll (>= 3.0, < 5.0)
     jekyll-paginate (1.1.0)
-    jekyll-readme-index (0.2.0)
-      jekyll (~> 3.0)
-    jekyll-redirect-from (0.14.0)
-      jekyll (~> 3.3)
-    jekyll-relative-links (0.6.0)
-      jekyll (~> 3.3)
-    jekyll-remote-theme (0.4.0)
+    jekyll-readme-index (0.3.0)
+      jekyll (>= 3.0, < 5.0)
+    jekyll-redirect-from (0.16.0)
+      jekyll (>= 3.3, < 5.0)
+    jekyll-relative-links (0.6.1)
+      jekyll (>= 3.3, < 5.0)
+    jekyll-remote-theme (0.4.3)
       addressable (~> 2.0)
-      jekyll (~> 3.5)
-      rubyzip (>= 1.2.1, < 3.0)
+      jekyll (>= 3.5, < 5.0)
+      jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
+      rubyzip (>= 1.3.0, < 3.0)
     jekyll-sass-converter (1.5.2)
       sass (~> 3.4)
-    jekyll-seo-tag (2.5.0)
-      jekyll (~> 3.3)
-    jekyll-sitemap (1.2.0)
-      jekyll (~> 3.3)
-    jekyll-swiss (0.4.0)
-    jekyll-theme-architect (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-seo-tag (2.8.0)
+      jekyll (>= 3.8, < 5.0)
+    jekyll-sitemap (1.4.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-swiss (1.0.0)
+    jekyll-theme-architect (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-cayman (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-cayman (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-dinky (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-dinky (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-hacker (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-hacker (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-leap-day (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-leap-day (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-merlot (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-merlot (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-midnight (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-midnight (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-minimal (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-minimal (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-modernist (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-modernist (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-primer (0.5.3)
-      jekyll (~> 3.5)
+    jekyll-theme-primer (0.6.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-github-metadata (~> 2.9)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-slate (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-slate (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-tactile (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-tactile (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-theme-time-machine (0.1.1)
-      jekyll (~> 3.5)
+    jekyll-theme-time-machine (0.2.0)
+      jekyll (> 3.5, < 5.0)
       jekyll-seo-tag (~> 2.0)
-    jekyll-titles-from-headings (0.5.1)
-      jekyll (~> 3.3)
+    jekyll-titles-from-headings (0.5.3)
+      jekyll (>= 3.3, < 5.0)
     jekyll-watch (2.2.1)
       listen (~> 3.0)
-    jemoji (0.10.2)
-      gemoji (~> 3.0)
+    jemoji (0.13.0)
+      gemoji (>= 3, < 5)
       html-pipeline (~> 2.2)
-      jekyll (~> 3.0)
-    kramdown (1.17.0)
-    liquid (4.0.0)
-    listen (3.1.5)
-      rb-fsevent (~> 0.9, >= 0.9.4)
-      rb-inotify (~> 0.9, >= 0.9.7)
-      ruby_dep (~> 1.2)
+      jekyll (>= 3.0, < 5.0)
+    json (2.13.2)
+    kramdown (2.4.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.4)
+    listen (3.9.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    logger (1.6.6)
     mercenary (0.3.6)
-    mini_portile2 (2.4.0)
-    minima (2.5.0)
-      jekyll (~> 3.5)
+    mini_portile2 (2.8.9)
+    minima (2.5.1)
+      jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.12.2)
-    multipart-post (2.1.1)
-    nokogiri (1.10.8)
-      mini_portile2 (~> 2.4.0)
-    octokit (4.14.0)
-      sawyer (~> 0.8.0, >= 0.5.3)
+    minitest (5.25.5)
+    net-http (0.6.0)
+      uri
+    nokogiri (1.18.9)
+      mini_portile2 (~> 2.8.2)
+      racc (~> 1.4)
+    octokit (4.25.1)
+      faraday (>= 1, < 3)
+      sawyer (~> 0.9)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
-    public_suffix (3.1.1)
-    rb-fsevent (0.10.3)
-    rb-inotify (0.10.0)
+    public_suffix (5.1.1)
+    racc (1.8.1)
+    rb-fsevent (0.11.2)
+    rb-inotify (0.11.1)
       ffi (~> 1.0)
-    rouge (2.2.1)
-    ruby-enum (0.7.2)
-      i18n
-    ruby_dep (1.5.0)
-    rubyzip (2.0.0)
+    rexml (3.4.1)
+    rouge (3.30.0)
+    rubyzip (2.4.1)
     safe_yaml (1.0.5)
     sass (3.7.4)
       sass-listen (~> 4.0.0)
     sass-listen (4.0.0)
       rb-fsevent (~> 0.9, >= 0.9.4)
       rb-inotify (~> 0.9, >= 0.9.7)
-    sawyer (0.8.2)
+    sawyer (0.9.2)
       addressable (>= 2.3.5)
-      faraday (> 0.8, < 2.0)
+      faraday (>= 0.17.3, < 3)
+    securerandom (0.4.1)
+    simpleidn (0.2.3)
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
-    thread_safe (0.3.6)
-    typhoeus (1.3.1)
+    typhoeus (1.4.1)
       ethon (>= 0.9.0)
-    tzinfo (1.2.5)
-      thread_safe (~> 0.1)
-    unicode-display_width (1.6.0)
+    tzinfo (2.0.6)
+      concurrent-ruby (~> 1.0)
+    unicode-display_width (1.8.0)
+    uri (1.0.3)
+    webrick (1.9.1)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
+  ffi (< 1.17.0)
   github-pages
+  webrick (~> 1.8)
 
 BUNDLED WITH
-   1.17.3
+   2.6.7
diff --git a/README.md b/README.md
index 440f209d..1926b533 100644
--- a/README.md
+++ b/README.md
@@ -1,14 +1,14 @@
 # Google Summer of Code Guides
 
-This project contains the Google Summer of Code Mentor Guide and Student Guide.
+This project contains the Google Summer of Code Mentor Guide and Contributor Guide.
 
 ## Template
 
 The template and build is based on
-https://github.com/tomjoht/documentation-theme-jekyll
+<https://github.com/tomjoht/documentation-theme-jekyll>
 
 Documentation can be found at
-http://idratherbewriting.com/documentation-theme-jekyll/
+<http://idratherbewriting.com/documentation-theme-jekyll/>
 
 ## Local Development
 
@@ -43,7 +43,7 @@ We need to do this because a) we're naming pages after their order, and b) the
 Next/Prev button requires all the order numbers to be contiguous.  You can't
 skip any.
 
-# Upgrade Ruby Gems
+## Upgrade Ruby Gems
 
 ```bash
 bundle install --path vendor/bundle
@@ -53,6 +53,13 @@ rm -rf vendor/bundle
 
 Don't forget to rebuild the docker image!
 
+## Run Markdownlint locally
+
+```shell
+npm install markdownlint-cli
+./node_modules/.bin/markdownlint  pages
+```
+
 ## Want to contribute?
 
 Please see the [CONTRIBUTING](CONTRIBUTING.md) instructions.
diff --git a/_config.yml b/_config.yml
index f181caee..2e537c95 100644
--- a/_config.yml
+++ b/_config.yml
@@ -28,9 +28,17 @@ host: 127.0.0.1
 port: 4000
 # the port where the preview is rendered. You can leave this as is unless you have other Jekyll builds using this same port that might cause conflicts. in that case, use another port such as 4006.
 
+# https://jekyllrb.com/docs/troubleshooting/
 exclude:
   - .idea/
   - .gitignore
+  - Gemfile
+  - Gemfile.lock
+  - node_modules
+  - vendor/bundle/
+  - vendor/cache/
+  - vendor/gems/
+  - vendor/ruby/
 # these are the files and directories that jekyll will exclude from the build
 
 #feedback_subject_line: Feedback Subject
diff --git a/_data/sidebars/mentor_sidebar.yml b/_data/sidebars/mentor_sidebar.yml
index 4f34866b..6e01ab36 100644
--- a/_data/sidebars/mentor_sidebar.yml
+++ b/_data/sidebars/mentor_sidebar.yml
@@ -23,7 +23,7 @@ entries:
     - title: Defining a Project (Ideas List)
       url: defining-a-project-ideas-list
       output: web
-    - title: Selecting a Student
+    - title: Selecting a Contributor
       url: selecting-a-student
       output: web
   - title: Communication
@@ -44,8 +44,8 @@ entries:
   - title: Mentoring
     output: web
     folderitems:
-    - title: Mind the Gap
-      url: mind-the-gap
+    - title: Community Bonding Period
+      url: community-bonding-period
       output: web
     - title: Setting Expectations
       url: setting-expectations
@@ -77,7 +77,7 @@ entries:
     - title: Making Your Ideas Page
       url: making-your-ideas-page
       output: web
-    - title: Selecting Students and Mentors
+    - title: Selecting Contributors and Mentors
       url: selecting-students-and-mentors
       output: web
     - title: Org Application
@@ -86,7 +86,7 @@ entries:
     - title: Managing Your Mentors
       url: managing-your-mentors
       output: web
-    - title: Student - Mentor Facilitation
+    - title: Contributor - Mentor Facilitation
       url: student-mentor-facilitation
       output: web
     - title: Other Possible Issues
diff --git a/_data/sidebars/student_sidebar.yml b/_data/sidebars/student_sidebar.yml
index 32618c69..8c52a2a1 100644
--- a/_data/sidebars/student_sidebar.yml
+++ b/_data/sidebars/student_sidebar.yml
@@ -1,6 +1,6 @@
 entries:
 - title: sidebar
-  product: Student Guide
+  product: Contributor Guide
   folders:
   - title: Introduction
     output: web
@@ -56,7 +56,7 @@ entries:
     - title: Working With Your Mentor
       url: working-with-your-mentor
       output: web
-    - title: Time management for students
+    - title: Time management for contributors
       url: time-management-for-students
       output: web
     - title: Evaluations
diff --git a/_includes/topnav.html b/_includes/topnav.html
index 064a7bc3..30715638 100644
--- a/_includes/topnav.html
+++ b/_includes/topnav.html
@@ -8,7 +8,7 @@
                 <span class="icon-bar"></span>
                 <span class="icon-bar"></span>
             </button>
-            <a class="navbar-brand" href="{{site.baseurl}}/"><img src="{{site.baseurl}}/images/sun-small.png"><span class="projectTitle"> {{site.topnav_title}}</span></a>
+            <a class="navbar-brand" href="{{site.baseurl}}/"><img src="{{site.baseurl}}/images/sun-small.png" alt="Google Summer of Code Logo"><span class="projectTitle"> {{site.topnav_title}}</span></a>
         </div>
         <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
             <ul class="nav navbar-nav navbar-right">
diff --git a/pages/index.md b/pages/index.md
index 605b9cc7..1449e44f 100644
--- a/pages/index.md
+++ b/pages/index.md
@@ -4,4 +4,4 @@ permalink: index.html
 ---
 
 * [Mentor Guide](mentor/)
-* [Student Guide](student/)
+* [Contributor Guide](student/)
diff --git a/pages/mentor/00-what_is_google_summer_of_code.md b/pages/mentor/00-what_is_google_summer_of_code.md
index f3cc19ae..b02528de 100644
--- a/pages/mentor/00-what_is_google_summer_of_code.md
+++ b/pages/mentor/00-what_is_google_summer_of_code.md
@@ -6,70 +6,67 @@ permalink: mentor/index
 sidebar: mentor_sidebar
 ---
 
-Google Summer of Code (GSoC) is a program that matches mentoring organizations with college and university student developers who are paid to write open source code. Each year, Google works with many open source, free software and technology-related groups to identify and fund proposals for student open source projects.
+Google Summer of Code (GSoC) is a global, online program that brings new contributors into open source software organizations. The program began in 2005 and until 2021 was focused on bringing university students into open source. Starting in 2022, we have expanded the program to welcome students and all beginner contributors to open source who are 18 years and older to apply to the program as GSoC Contributors. These GSoC Contributors will write code and become part of these open source communities while making some money along the way. The organizations provide mentors who act as guides through the entire process, from learning about the community, to helping GSoC Contributors become familiar with the code base and testing practices, to finally releasing their code for the world to use! The ultimate goal is that these GSoC Contributors will become excited about the communities they are involved with during the program and will continue to actively contribute to the communities long after their GSoC program ends - or maybe start their own open source project!
 
-GSoC pairs accepted student applicants with mentors from participating projects. Accepted students gain exposure to real-world software development and an opportunity for employment in areas related to their academic pursuits. In turn, participating organizations are able to identify and bring in new developers more easily. Best of all, more source code is created and released for the use and benefit of all; all code produced as part of the program is released under an open source license.
-
-This program has brought together thousands of students and mentors from over 118 countries worldwide. Over 680 open source projects, from areas as diverse as operating systems and community services, have participated as mentor organizations for the program. Successful students have widely reported that their participation in GSoC made them more attractive to potential employers and that the program has helped greatly when embarking on their technical careers.
+Accepted GSoC Contributors gain exposure to real-world software development while having their mentor(s) ready to help integrate them into the community and help them become stronger developers. Best of all, more source code is created and released for the use and benefit of all; all code produced as part of the program is released under an open source license. The fact that you get to write code that people from all over the world can use - how cool is that!
 
+Since 2005, GSoC has brought together 41,000 new contributors to open source and mentors from over 138 countries worldwide. As of January 2025, over 1,000 open source projects, from areas as diverse as operating systems and community services, have participated as mentoring organizations for the program. Successful students have widely reported that their participation in GSoC made them more attractive to potential employers and that the program has helped greatly when embarking on their technical careers. Many past GSoC contributors continue to be involved in GSoC by becoming mentors themselves and helping new contributors learn about the exciting things their community is working on and the satisfaction that comes with being a part of a community of dedicated developers in open source.
 
 ## Goals of the Program
 
-The program has several goals:
-
-*   Get more open source code written and released for the benefit of all.
-*   Inspire young developers to begin participating in open source development.
-*   Help open source projects identify and bring in new developers.
-*   Provide students the opportunity to do work related to their academic pursuits during the summer: "flip bits, not burgers."
-*   Give students more exposure to real-world software development (for example, distributed development and version control, software licensing issues, and mailing list etiquette).
+The GSoC program has several goals:
 
+* Inspire developers to begin participating in open source development.
+* Help open source projects identify and bring in new developers.
+* Get more open source code written and released for the benefit of all.
+* Give newer developers more exposure to real-world software development (for example, distributed development and version control, software licensing issues, testing, and communication best practices).
 
 ## A Brief History of Google Summer of Code
 
-Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. In GSoC's first year, 40 projects and 400 students participated. By the conclusion of the fifteenth Google Summer of Code in 2019, over 15,000 students have been accepted into the program. Best of all, most of the organizations participating have reported that the program helped them find new community members and active committers.
+Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. In GSoC’s first year, 40 projects and 400 students participated. By the conclusion of the 20th Google Summer of Code in 2024, over 21,000 students/GSoC contributors have been accepted into the program. Best of all, most of the organizations participating over the past 20 years reported that the program helped them find new community members and active committers.
 
-See the appendix for a more extensive history of the program.
+GSoC has grown immensely over the last 20 years and in the process helped participants learn about real world software development while working on exciting open source projects.
 
+You can take a look at the appendix if you’re interested in a more extensive history of the program.
 
 ## Participant Roles
 
 There are four roles in the Google Summer of Code program:
 
-**Program Administrator**: Program administrators are employees of Google's Open Source Programs Office who run the program. These folks do a variety of tasks: select the participating open source projects each year, create and analyze the program evaluations, administer the program mailing lists, ensure that participants are paid, and send out the all-important program t-shirt. Program administrators do not select which student proposals are accepted into Google Summer of Code.
+**Program Administrator**: Program administrators are employees of Google's Open Source Programs Office who run the program. These folks do a variety of tasks: select the participating open source projects each year, create and analyze the program evaluations, administer the program mailing lists, and ensure that participants are paid, maintain the web application, etc. Program administrators do not select which proposals are accepted into Google Summer of Code.
 
-More broadly, program administrators provide useful advice to both new and seasoned participants in a variety of areas, relying on their experience with the program and mentoring process. Not sure how to handle a disappearing student? Don't know which mailing list has the latest information on payments? Wondering how to best improve your organization's application for the program? Find a program administrator and ask away!
+More broadly, program administrators provide useful advice to both new and seasoned participants in a variety of areas, relying on their experience with the program and mentoring process. Not sure how to handle a disappearing student? Wondering how to best improve your organization's application for the program? Find a program administrator and ask away!
 
-**Organization Administrator**: Org admins are the "cat herders" for GSoC open source projects. These people submit the organization's application to participate in the program to Google, ensure that mentors fill out evaluations in a timely fashion, and generally organize their project's participation in GSoC. The org admin acts as Google's go-to person if any issues arise. There are also some trivial administrative tasks in GSoC's online system that can only be completed by organization administrators. Some org admins also mentor students during GSoC, and that's perfectly fine; it is just highly recommended that folks know they have enough time to execute both roles simultaneously.
+**Organization Administrator**: Org admins are the "cat herders" for GSoC open source projects. These people submit the organization's application to participate in the program to Google, including making sure the Project Ideas list is solid, ensuring that mentors fill out evaluations in a timely fashion, and generally organize their project's participation in GSoC. The org admin acts as Google's go-to person if any issues arise. There are also some administrative tasks in GSoC's online system that can only be completed by organization administrators. Some org admins also mentor GSoC contributors during GSoC, and that's perfectly fine; it is just highly recommended that folks know they have enough time to execute both roles simultaneously.
 
-Org admins are the final authority about matters such as which student projects will be accepted and who will mentor whom. On the social side, if a mentor and student have difficulties communicating or making progress, an org admin will often step in as a neutral party to help the two work together more effectively. Org admins also help track down disappearing participants, whether mentors or students.
+Org admins are the final authority about matters such as which GSoC contributor projects will be accepted, who will mentor whom, and what the end date will be for a coding project. On the social side, if a mentor and GSoC contributor have difficulties communicating or making progress, an org admin will often step in as a neutral party to help the two work together more effectively. Org admins also help track down disappearing participants, whether mentors or GSoC contributors.
 
-**Mentor**: Mentors are people from the community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student contributors integrate into their project's community. Some organizations choose to assign more than one mentor to each of their students. Many members of the community provide guidance to their project's GSoC students without mentoring in an "official" capacity, much as they would answer anyone's questions on the project's mailing list or IRC channel.
+**Mentor**: Mentors are people from the community who volunteer to work with a GSoC contributor. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing GSoC contributors with feedback and pointers, a mentor acts as an ambassador to help GSoC contributors integrate into their project's community. Some organizations choose to assign more than one mentor to each of their GSoC contributors. Many members of the community provide guidance to their project's GSoC contributors without mentoring in an "official" capacity, much as they would answer anyone's questions on the project's mailing list or chat channel.
 
-**Student**: A student participant in GSoC is typically a college or university student;  the only academic requirement is that the accepted applicants be enrolled in an accredited academic institution. Students must also be at least 18 years of age in order to participate. Students come from a variety of academic backgrounds, and though most students are enrolled in a Computer Science program there is no requirement that they be studying CS; past student participants in GSoC have come from disciplines as varied as Ecology, Medicine, and Music.
-
-Students submit project proposals to the various organizations participating in GSoC. The organizations select which student proposals they would like to see funded by Google. Many student participants have gone on to become important members of the open source community. Many students have also gone on to become mentors and even org admins for the program.
+**GSoC contributor**: A GSoC contributor is a person new to open source development who is excited to learn more about the community. GSoC contributors must be at least 18 years of age in order to participate (and from a non-US embargoed country). This person could be a university student, a recent graduate, a person switching careers, a developer early in their career, person returning to the workforce, etc. GSoC Contributors come from a variety of academic backgrounds - many are university students or graduates of coding schools or programs, while others are self-taught.
 
+Potential GSoC contributors submit project proposals to the various organizations participating in GSoC. The organizations select which proposals they would like to see funded by Google. Many GSoC contributors have gone on to become important members of the open source community. Many GSoC contributors have also gone on to become mentors and even org admins for the program.
 
 ## Program Structure
 
 All of the program rules are enumerated in the GSoC Program Rules and Term documents each year. Provided all of the rules regarding eligibility for the program are followed, Google takes a fairly hands-off approach to GSoC. Each organization structures its participation in GSoC in whichever way makes the most sense for its technical and community needs.
 
-**Organization Applications**: The GSoC program is announced each year on the [Google Open Source Blog](https://opensource.googleblog.com/) among other places, and this announcement provides application deadlines for projects. Each organization must apply to participate. Organizations usually have about 2 weeks to apply for the program. Google's program administrators then select which organizations will participate in that year's Google Summer of Code.
-
-**Student Applications**: Students are encouraged to begin talking to the participating organizations as soon as the list of accepted organizations is published. Prior to the opening of applications, it is important to take some time to talk to potential student applicants. This helps them refine their ideas so that they will produce a better quality proposal. Each organization is asked to provide a proposal template, but the best student applications go far beyond the template and an organization's ideas list. Students are given about 2 weeks to complete their applications.
+**Organization Applications**: The GSoC program is announced each year on the [Google Open Source Blog](https://opensource.googleblog.com/) among other places, and this announcement provides application deadlines for projects. Each organization must apply to participate. Organizations usually have about 3 weeks to apply for the program. Google's program administrators then select which organizations will participate in that year's Google Summer of Code.
 
-Following the student application deadline, organizations begin reviewing the proposals they received. During the review phase, organizations maintain an open dialogue with their student applicants. This may involve clarifying questions in regards to the final proposals to ensure students and organizations have the same understanding of the proposal. It is important to note a student's proposal can't be altered after the final submission deadline, and mentor orgnizations should not attempt to do so during the review period. 
+**GSoC Contributor Applications**: Potential GSoC contributors are encouraged to begin talking to the participating organizations as soon as the list of accepted organizations is published. Prior to the opening of applications, it is important to take some time to talk to potential applicants. This helps them refine their ideas so that they will produce a better quality proposal. Each organization is asked to provide a proposal template, but the best applications go far beyond the template and an organization's ideas list. Applicants are given about 2 weeks to complete their applications.
 
-Organizations may also conduct further interviews to determine which students are most likely to be a good fit for the community and work required. Over the course of several weeks, each organization prioritizes its list of proposals. Google lets each organization know how many student proposals it will fund, and organizations select their top proposals.
+Following the GSoC contributor application deadline, organizations begin reviewing the proposals they received. During the review phase, organizations maintain an open dialogue with their applicants. This may involve clarifying questions in regards to the final proposals to ensure applicants and organizations have the same understanding of the proposal. It is important to note an applicant's proposal can't be altered after the final submission deadline, and mentor organizations should not attempt to do so during the review period.
 
-Sometimes a student has proposals accepted by more than one organization. Google leaves it to the organizations to decide which organization the student will work with during the course of the program.
+Organizations may also conduct further interviews to determine which applicants are most likely to be a good fit for the community and work required. Over the course of several weeks, each organization prioritizes its list of proposals, ranking them and then submitting their requests for slots to Google. Google will let each organization know how many slots it will fund, and based on ranked order those proposals will be automatically selected (if given 5 slots, those proposals ranked 1-5 will be selected).
 
-**Community Bonding Period**: Before students are expected to start working, there is a three-four week period built into the program to allow them to get up to speed without the pressure to execute on their proposals. During this time, students are expected to get to know their project communities and participate in project discussion. During this time, students should also set up their development environments, learn how their project's source control works, refine their project plans, read any necessary documentation, and otherwise prepare to complete their project proposals. Mentors should spend this time helping their students understand which resources will be most useful to them, introducing them to the members of the community who will be most helpful with their projects, and generally acculturating them.
+Sometimes an applicant has proposals accepted by more than one organization. Google leaves it to the organizations to decide which organization the student will work with during the course of the program.
 
-**Start of Coding**: Start of coding is the date the program officially begins; students are expected to start executing on their project proposals. At this point, students should begin regular check-ins and regular patch submissions.
+**Community Bonding Period**: Before GSoC contributors are expected to start working, there is a three week period built into the program to allow them to get up to speed without the pressure to execute on their proposals. During this time, GSoC contributors are expected to get to know their project communities and participate in project discussion. During this time, GSoC contributors should also set up their development environments, learn how their project's source control works, refine their project plans, read any necessary documentation, and otherwise prepare to complete their project proposals. Mentors should spend this time helping their GSoC contributors understand which resources will be most useful to them, introducing them to the members of the community who will be most helpful with their projects, and generally acculturating them.
 
-**Coding Ends**: At the final deadline for coding, students are welcome and encouraged to continue work on their projects, but only work done before this date can be evaluated. Google suggests that all work be complete about a week earlier to give the student time for last-minute improvements and corrections, as well as preparing their work for delivery. Students also need to submit mentor evaluations during this time and a link to their code.
+Since 2022 there is increased flexibility in the timeline for projects. When proposals are submitted they will be selected as a small (90 hour), medium (175 hour) or large (350 hour) project. The standard coding period will be 12 weeks for medium and large projects and 8 weeks for small projects. However, GSoC contributors can request (in their proposal) to have a longer coding period to complete their project as they know they may have various other commitments or certain weeks when they will not be able to commit as much time to their GSoC project (up to a 22 week coding period is allowed). This opens it up for the GSoC contributors and mentor to decide together how they want to break up the project. Some folks may choose to stick to a certain number of hours a week schedule with their GSoC contributors, others may factor in a couple of breaks during the program (for GSoC contributor and mentor). This also makes it a lot easier for GSoC contributors with finals or other commitments (weddings, moving across the country, etc.) to adjust their schedules. But the most important thing to remember is that both the GSoC contributor and mentor should agree on a schedule and sign off on it early on during the community bonding period so there is no confusion later on.
 
-It's a goal of Google Summer of Code that the student participants stick around long after the program has ended and continue contributing to their project communities. Great mentors continue working with their students to encourage them to do so. It's also customary during this time for organizations to publish a post-GSoC wrap up report. Mentors and students take a well-deserved break, but energetic organizations begin planning for the next GSoC during this time.
+**Start of Coding**: Start of coding is the date the program officially begins; GSoC contributors are expected to start executing on their project proposals. At this point, GSoC contributors should begin regular check-ins and regular patch submissions.
 
+**Coding Ends**: At the final deadline for coding, GSoC contributors are welcome and encouraged to continue work on their projects, but only work done before this date can be evaluated. Google suggests that all work be complete about a week earlier to give the GSoC contributor time for last-minute improvements and corrections, as well as preparing their work for delivery. GSoC contributors also need to submit mentor evaluations during this time and a link to their code.
 
+It's a primary goal of Google Summer of Code that the GSoC contributors stick around long after the program has ended and continue contributing to their project communities. Great mentors continue working with their GSoC contributors to encourage them to do so. It's also customary during this time for organizations to publish a post-GSoC wrap up report. Mentors and GSoC contributors take a well-deserved break, but energetic organizations begin planning for the next GSoC during this time.
diff --git a/pages/mentor/01-why_gsoc_matters.md b/pages/mentor/01-why_gsoc_matters.md
index 182f6506..2ab288f7 100644
--- a/pages/mentor/01-why_gsoc_matters.md
+++ b/pages/mentor/01-why_gsoc_matters.md
@@ -8,34 +8,36 @@ sidebar: mentor_sidebar
 
 In addition to the great code produced, the GSoC experience is about building open source communities. By focusing on students, we are going to the source of all future open source efforts. The ultimate success of the GSoC program is thus measured by the quality of the student experience. Each organization and each mentor plays a crucial role in creating this experience through their project ideas, developer culture, and the guidance they provide. They are rewarded by new code and by adding skilled new developers to their ranks. But don't take our word for it! Heres what some of the students had to say:
 
+<!-- markdownlint-disable no-blanks-blockquote -->
 > Overall, this is the most productive summer I ever had. It increased my confidence as a developer and as a person that I can actually pull off a project like this and interact with awesome people like you. I also become a part of a growing community and hope to help it grow further.
-> 
+>
 > *—Chetan Bansal*
 
 > There aren't many opportunities for computational biology enthusiasts to make a difference in the field while still in school. GSOC at [my org] was one such gem of an opportunity that illustrated exactly why writing software for biological research is benefited by a background in biology. The experience I have gained here is definitely irreplaceable. The fundamentals of open-source programming and the rhythm associated with regular coding and problem solving helped nourish an intellectual side of me that I will not forget in a hurry. This is definitely not the last time you will see me.
-> 
+>
 > *—Chinmoy Bhatiya*
 
 > This was the first time I took part into either GSoC or an Open Source project, and it was also one of the most exciting things I've ever done! This project gave me the chance to spend ~3 months learning lot of new things, having fun, doing something for the community and even getting pay for that! That's an amazing combination! --I will remain as an active participant of [my org's] community beyond the official end of GSoC 2009!
-> 
+>
 > *—Gerardo Huck*
 
 > It was definitely a very good learning experience for me. --But I have some unfinished works-- So I'll continue this project after GSoC, and be help to drive [my org's] development.
-> 
+>
 > *—Kozo Nishida*
 
 > It was the first time that I worked with an open source community and it was really a great experience. I am very thankful to Google and [my org] for providing me this great opportunity. I would like to thank [my mentors] for their excellent support during the summer. Looking forward to working with you again.
-> 
+>
 > *—Srinivasarao Vundavalli*
 
 > Get over yourself. Understand there are people smarter than you or people better at some things than you. Just the same, you're still needed. JFDI (Just Fabulously Do It) and find your niche.
-> 
+>
 > *—Justin Hunter*
 
 > This year's GSoC was my first contribution to the open source world and I will like to continue my contributions to open source whenever I get the opportunity. The best thing about open source is the huge opportunity it provides to everyone who wants to explore their career in the technical world and develop in their field of interest. The way people from different streams come together, exploit their talents, cooperate, coordinate, focus their collective efforts towards a common goal that will help many more people in the end is the best part about open source.
-> 
+>
 > *—Kanika Vats*
 
 > So, we've now gotten to the end of it all. It does feel a bit sad, I really did have a great time coding this summer and hopefully I can do it again. I don't think I've ever learned this much in a summer job and everybody working with me have been really fantastic.
-> 
+>
 > *—Anna Granudd*
+<!-- markdownlint-enable no-space-in-emphasis -->
diff --git a/pages/mentor/02-notes_for_first_year_organizations.md b/pages/mentor/02-notes_for_first_year_organizations.md
index 20bc9378..d0ef8a4b 100644
--- a/pages/mentor/02-notes_for_first_year_organizations.md
+++ b/pages/mentor/02-notes_for_first_year_organizations.md
@@ -8,53 +8,59 @@ sidebar: mentor_sidebar
 
 Dear First Year Organization,
 
-Congrats! We know you're excited to participate in GSoC. We also know it can be overwhelming, but remember the GSoC team has done this before and knows what it's doing. The program is well documented - here are a few tips to get your started.
+Congrats! We know you're excited to participate in GSoC. We also know it can be overwhelming, but remember the GSoC team has done this before and knows what it's doing. The program is well documented - here are a few tips to get you started.
 
 General:
 
-* This is about building the STUDENT'S experience. Getting code in your project is a nice side effect.
+* This is about building the GSOC CONTRIBUTOR'S experience. Getting code in your project is a nice side effect.
 
-* Know and meet the deadlines for every part of participation: organization administration, student participation, and mentor participation. Use Google Calendars' alert feature.
+* Know and meet the deadlines for every part of participation: organization administration, GSoC contributor participation, and mentor participation. Use Google Calendars' alert feature and look at your GSoC dashboard at least once a week to remind you of upcoming deadlines.
 
-* Search the site and the Resources section in particular, but don't be afraid to ask questions on the appropriate mailing list, particularly the GSoC Mentor List.
+* Search the site and the Help section in particular, but don't be afraid to ask questions on the appropriate mailing list, particularly the GSoC Mentor List.
+
+* Read the emails GSoC Admins send to you. All of the information for each step of the program is in these emails. If you don't check the email address you provide for GSoC then you will need to change your habits to check those emails. The few emails tend to be long and filled with a lot of information rather than sending dozens of emails throughout the program. Each email will have many helpful links included to help you with the current and next stage of the program.
 
 * Talk to experienced organizations for advice; talk to new organizations for brainstorming.
 
 * Spread (don't spam) the word that your organization is participating in GSoC.
 
-Students, mentors, and slots:
+GSoC contributors, mentors, and project slot requests:
 
-* Students are not experienced project members and will take longer to write code than the core team. Plan accordingly.
+* GSoC contributors are not experienced project members and will take longer to write code than the core team. Plan accordingly.
 
-* Mentors should expect to spend about 4-5 hours a week for each student. Some weeks may be more, some weeks less. More time spent during the community bonding period and the first few weeks of the program have led to more successful and engaged students.
+* Mentors should expect to spend about 2-4 hours a week for each GSoC contributor. Some weeks may be more, some weeks less. More time spent during the community bonding period and the first few weeks of the program have led to more successful and engaged GSoC contributors.
 
-* The mentor/student process is:
+* The mentor/GSoC contributor process is:
 
-    * OAs invite mentors to their organization.
+  * OAs invite mentors to their organization.
 
-    * Talk with students about project ideas (some orgs give students a task they need to complete, that is up to you).
+  * Talk with potential GSoC contributors about project ideas (some orgs give applicants a task they need to complete such as a PR, a small test, etc., that is up to you). **If you want to select the best GSoC contributor for your project you MUST talk to the contributor. With the rise in AI anyone can write a great proposal but that doesn't mean they can do any of the things in the proposal or they even understand what it is your org does.**
 
-    * Receive and review student applications.
+  * Receive and review GSoC contributor applications.
 
-    * Request a minimum and a maximum number of requested slots for students. (OAs submit requests)
+  * Determine which mentors are fully committed to mentor a proposal.
+  
+  * Rank your excellent proposals with dedicated mentors. (OAs submit requests)
 
-    * Receive confirmation from Program Administrators with your organization's number of slots.
+  * Receive confirmation from Program Administrators with your organization's number of slots.
 
-    * Select students and mentors for each project.
+  * The number of slots will determine which ranked proposals are automatically selected. If your org asks for 7 slots but is given 5, ranked proposals #1-#5 will automatically be selected as your org's GSoC contributor projects.
 
-* The application process is a great initial test of the student's dedication and skills, so don't offer students too much help during it. Feedback is good but if you have to hand hold them now, it will be worse during the program.
+* The application process is a great initial test of the GSoC contributor's dedication and skills, so don't offer too much help during it. Feedback is good but if you have to hand hold them now, it will be worse during the program. Do not base your decisions solely on the proposal. Orgs should heavily weigh the interactions with the community when selecting their GSoC contributors. Especially with more developers using AI to write proposals, a wonderful proposal can proove meaningless if the person can't even do a pull request.
 
-* Use code tests and personal conversation to help select students. The student with the best proposal might not be the student who can produce the best code.
+* Use code tests and personal conversation to help select GSoC contributors. The applicant with the best proposal might not be the applicant who can produce the best code.
 
-* Request 1 student slot for every 2 mentors you have. As a first year organization you will probably receive fewer than 3 students. THIS IS A GOOD THING. Use your first year to get used to the process. Expand in your second year.
+* Request 1 GSoC contributor slot for every 2 mentors you have. As a first year organization you will probably receive 1-2 GSoC contributors. THIS IS A GOOD THING. Use your first year to get used to the process. Expand in your second year.
 
 Coding, community, and communication:
 
-* Treat the student like a core contributor. Private repos or branches can prevent the student from blocking releases, but can also isolate the student from the rest of the project.
+* Treat the GSoC contributor like a core contributor. Private repos or branches can prevent the GSoC contributors from blocking releases, but can also isolate them from the rest of the project.
+
+* Publish weekly or daily goals. This helps to keep scope, show progress, and keep GSoC contributors active.
 
-* Publish weekly or daily goals. This helps to keep scope, show progress, and keep students active.
+* Communicate often and be sure to talk with your GSoC contributor about their roadblocks/delays. You may wish to extend the evaluation deadlines for your contributor by a few weeks if the contributor is behind schedule but putting in the effort. But remember - extensions must occur before the GSoC contributor's midterm evaluation or final submission period begins.
 
-* It's okay to fail a student. If a student doesn't meet agreed deadlines or doesn't communicate, he or she should be failed.
+* It's okay to fail a GSoC contributor. If a GSoC contributor doesn't communicate, or they disappear for days/weeks on end, they write poor code and haven't shown signs of improvement or they aren't engaged in the community they should be failed.
 
 * Make all communication public. If it didn't happen in public, it didn't happen.
 
@@ -65,5 +71,3 @@ If you have any questions just ask. We know you'll be awesome!
 Best wishes,
 
 One time GSoC First Year Organizations
-
-
diff --git a/pages/mentor/03-what_makes_a_good_mentor.md b/pages/mentor/03-what_makes_a_good_mentor.md
index 61d1340f..50687607 100644
--- a/pages/mentor/03-what_makes_a_good_mentor.md
+++ b/pages/mentor/03-what_makes_a_good_mentor.md
@@ -6,34 +6,30 @@ permalink: mentor/what-makes-a-good-mentor.html
 sidebar: mentor_sidebar
 ---
 
-Mentoring a student can be a very rewarding experience. However, being a good mentor is *not* just a matter of winding up the student and watching them go. Quality mentoring requires a substantial time commitment and the willingness and ability to take a leadership role.
+Mentoring a GSoC contributor can be a very rewarding experience. However, being a good mentor is *not* just a matter of winding up the GSoC contributor and watching them go. Quality mentoring requires a substantial time commitment and the willingness and ability to take a leadership role.
 
 There are specific skills that you can work on in order to be more effective; even experienced mentors can improve. This chapter highlights some of the capabilities of top mentors, by suggesting some self-assessment questions that can help you to evaluate your strengths and weaknesses in this role.
 
-**Are you already part of the developer community?** If you are not then you are going to be less effective at introducing a student to the local culture and practices. Similarly, you are less likely to be able to propose, guide and integrate successful projects relevant to the larger effort. If you are new to the community, working as a backup mentor on a project may be an excellent way to get involved.  Note that some projects are more community-oriented than others; assess the community skillset needed for your target group.
+**Are you already part of the developer community?** If you are not then you are going to be less effective at introducing a GSoC contributor to the local culture and practices. Similarly, you are less likely to be able to propose, guide and integrate successful projects relevant to the larger effort. If you are new to the community, working as a backup mentor on a project may be an excellent way to get involved.  Note that some projects are more community-oriented than others; assess the community skillset needed for your target group.
 
 **Do you have a real interest in potential GSoC projects?** As a GSoC mentor you will be taking ownership of a project idea and seeing it through the summer. If you are not excited about the project, mentoring will be more difficult. You are an integral part of the process from project proposal to delivery.
 
 **Are you willing to dedicate significant time?** While the time requirements for mentoring vary, you should seriously consider your prior mentoring experiences and your available time before committing to this role. If you really don't want to mentor, or really won't have a reasonable amount of time each week, *then don't offer.*
 
-**Are you keenly interested in mentoring students?** A main goal of GSoC is mentoring students. Mentoring is important to the future of open source software, our immediate projects and the overall culture. Mentoring a student requires a combination of passion, responsibility and patience. A good mentor is willing to engage with students throughout their learning process.
-
+**Are you keenly interested in mentoring GSoC contributors?** A main goal of GSoC is mentoring GSoC contributors. Mentoring is important to the future of open source software, our immediate projects and the overall culture. Mentoring a GSoC contributor requires a combination of passion, responsibility and patience. A good mentor is willing to engage with GSoC contributors throughout their learning process.
 
 ## Be Prepared to Seek Help
 
-At all times don't forget that you have access to people, tools and resources that can make your job much easier *and* make you a better mentor. Make use of your org admin when you are not sure what is expected of you or have a difficult situation with your student. Make use of other mentors in your organization and the thousands of mentors on the mentor mailing list. Though it may be an annoying list at times *(don't feed the trolls!)*, it is a valuable resource. The GSoC admins are another important resource. They set the tone and standards for the entire program. They have heard it all, so don't hesitate to contact them when a problem arises.
-
+At all times don't forget that you have access to people, tools and resources that can make your job much easier *and* make you a better mentor. Make use of your org admin when you are not sure what is expected of you or have a difficult situation with your GSoC contributor. Make use of other mentors in your organization and the thousands of mentors on the mentor mailing list. Though it may be an annoying list at times *(don't feed the trolls!)*, it is a valuable resource. The GSoC admins are another important resource. They set the tone and standards for the entire program. They have heard it all, so don't hesitate to contact them when a problem arises.
 
 ## What To Expect From Under-Mentoring
 
-**The student's project is never properly defined.** The project goals and deliverables are unclear, and the work schedule is not set. The consequences of this are serious and impact the project if left unchecked.
-
-**The mentor has little idea what the student is doing.** The state of the project is unclear, and its progress is uncertain. Evaluation is impossible to do well.
-
-**The student produces code that isn't useful.**  The student starts off on 'the wrong path',  failing to use existing functions or established project idioms.  Rather than fixing problems as they arise they keep on adding more.  The code is never integrated into the main codebase because it doesn't work well enough and would require more work to fix than it is worth.
+**The GSoC contributor's project is never properly defined.** The project goals and deliverables are unclear, and the work schedule is not set. The consequences of this are serious and impact the project if left unchecked.
 
-**The student gets stuck.** The student seems to be engaged, and to be working hard, but no apparent progress is being made. Alternatively, the student's communications are infrequent and terse, and seem to always be on the same issue or milestone.
+**The mentor has little idea what the GSoC contributor is doing.** The state of the project is unclear, and its progress is uncertain. Evaluation is impossible to do well.
 
-**The student disappears, perhaps for days or weeks at a time.** If the student is under-mentored, it may be difficult to determine when this period began, and thus to know when to panic. Insufficient information is available for evaluation; thus it becomes impossible to fairly evaluate the student.
+**The GSoC contributor produces code that isn't useful.**  The GSoC contributor starts off on 'the wrong path',  failing to use existing functions or established project idioms.  Rather than fixing problems as they arise they keep on adding more.  The code is never integrated into the main codebase because it doesn't work well enough and would require more work to fix than it is worth.
 
+**The GSoC contributor gets stuck.** The GSoC contributor seems to be engaged, and to be working hard, but no apparent progress is being made. Alternatively, the GSoC contributor's communications are infrequent and terse, and seem to always be on the same issue or milestone.
 
+**The GSoC contributor disappears, perhaps for days or weeks at a time.** If the GSoC contributor is under-mentored, it may be difficult to determine when this period began, and thus to know when to panic. Insufficient information is available for evaluation; thus it becomes impossible to fairly evaluate the GSoC contributor.
diff --git a/pages/mentor/04-defining_a_project__ideas_list.md b/pages/mentor/04-defining_a_project__ideas_list.md
index caa6af25..45a72010 100644
--- a/pages/mentor/04-defining_a_project__ideas_list.md
+++ b/pages/mentor/04-defining_a_project__ideas_list.md
@@ -10,27 +10,28 @@ The process of defining ideal GSoC projects is not just a "summertime" activity.
 
 Putting together a well-defined GSoC project also forces you to think about your project from a new point of view. This is a valuable exercise for defining the current scope of, and potential new avenues for, your work. In other words, it can be much more than just getting help with your existing workload.
 
-Your goal for GSoC is to generate a list of project ideas that capture the development needs of your organization, attract the interest of students, and help you get things done. This is often done as a community effort that involves as many potential mentors as possible, helps create buy-in from these mentors, and gives a broad range of perspectives on organizational needs. Creating your list of project ideas should also be part of an ongoing long-term strategy, rather than a rushed act to meet the application deadline. Many organizations maintain such project lists year-round.
+Your goal for GSoC is to generate a list of project ideas that capture the development needs of your organization, attract the interest of potential GSoC contributors, and help you get things done. This is often done as a community effort that involves as many potential mentors as possible, helps create buy-in from these mentors, and gives a broad range of perspectives on organizational needs. Creating your list of project ideas should also be part of an ongoing long-term strategy, rather than a rushed act to meet the application deadline. Many organizations maintain such project lists year-round.
 
-There is an art to writing a project description that leads to good student applications. It is tempting to write a detailed project plan for the student to follow. However, students tend to echo such plans in their applications, making it difficult to evaluate their quality. It is better to briefly describe a general high-level need, and the motivation behind that need. Keeping the scope modest helps encourage more applicants, while adding a "stretch" goal to the project description may encourage stronger students to take on the challenge of meeting it.
+There is an art to writing a project description that leads to good applications. It is tempting to write a detailed project plan for the GSoC contributor to follow. However, GSoC contributors tend to echo such plans in their applications, making it difficult to evaluate their quality. It is better to briefly describe a general high-level need, and the motivation behind that need. Keeping the scope modest helps encourage more applicants, while adding a "stretch" goal to the project description may encourage stronger GSoC contributors to take on the challenge of meeting it.
 
-One strategy is to leave an opening for students to propose their own original project ideas. Some great ideas can come out of this process. Emphasize that the student proposing something original must engage with the community strongly before or during the application period to get feedback and guidance to improve the proposal.
+One strategy is to leave an opening for GSoC contributors to propose their own original project ideas. Some great ideas can come out of this process. Emphasize that the GSoC contributors proposing something original must engage with the community strongly before or during the application period to get feedback and guidance to improve the proposal.
 
 **Writing a Good Ideas List**
 
 Note that the quality of the project descriptions on an organization's "Ideas list" is the main criterion for the organization's admittance into GSoC. It is worth spending some extra effort to ensure that the projects you propose are worthy of the GSoC banner.
 
-When Google Administrators review the hundreds of organization applications one of the main things they look at is the quality of the Ideas list. An Ideas list should follow these guidelines:
+When Google Administrators review the hundreds of organization applications the primary thing they look at is the quality of the Ideas list. An Ideas list should follow these guidelines:
 
-1.  Each project on the Ideas list should include: a) a project title/description  b) more detailed description of the project (2-5 sentences) c) expected outcomes  d) skills required/preferred  e) possible mentors. And if possible, an easy, medium or hard rating of each project.
-1.  Have multiple ideas. Even if you are a new organization and only want one or two students showing that you have multiple ideas (a bare minimum of 4 solid ideas) is vital. And for an organization hoping for 4 or more students you should have at least 8-10 ideas and having them categorized is a nice touch if you have subcategories of topics within your project.
-1.  Make it easy for Administrators to find your Ideas list. When reviewing many hundreds of organizations Program Admins can only spend a certain amount of time looking for your Ideas list. Many organizations are rejected because Program Admins couldn't find the actual Ideas list because the URL the org gave had a bunch of other unrelated information on it and wasn't clear where to find the actual Ideas list.
-1.  Make sure to update your Project Ideas. Even if you plan to use some of the ideas that weren't chosen from a previous year at least put effort into changing the page to say 20XX Ideas list. It is not encouraging for Program Admins to see an outdated list. It also makes it seem like your project might be stale as you don't have new ideas for students to work on if it still shows ideas from the previous year or even two years before and is marked as such.
-1.  **Never link to just a bug tracker**. This is almost always an automatic rejection. When Admins open the issue tracker if there is an expanded description of the project with the items listed in #1 above that is acceptable. If an org can't take the time to create a document or a page with their Ideas List fleshed out then why would Google expect they would be willing to mentor students for 5 hours a week for the next 4 months?
-1.  Don't be vague about the ideas. Be sure to write a few sentences describing what you need accomplished and not just an overall theoretical version of what you might want.
-1.  Be sure the URL you link to for your Ideas list works. Have someone else test it as well before you submit your application. Sometimes people don't have permissions set correctly or paste an incorrect URL which will also mean a rejection.
+1. Each project on the Ideas list should include: a) a project title/description  b) more detailed description of the project (2-5 sentences) c) expected outcomes  d) skills required/preferred  e) possible mentors f) expected size of project (90, 175 or 350 hour -- yes, 3 options starting in 2023). And if possible, an easy, medium or hard rating of each project. This helps the more inexperience folks not get overwhelmed and they can focus on reviewing easy project ideas.
+1. Projects should take ~90 hour, ~175 hours or ~350 hours for GSoC contributors to complete. We understand some GSoC contributors will take less time (if they have more knowledge of the topic or codebase) while others could spend more time. It is also possible that a given project idea could be 90 hours, 175 hours or 350 hours depending on the scope of the idea. If the GSoC contributor proposes to do a smaller scope of the idea then it might be a 175 hr project versus if they propose doing more work with their proposal it could be a 350 hour project.
+1. Have multiple ideas. Even if you are a new organization and only want one or two GSoC contributors showing that you have multiple ideas (a bare minimum of 4 solid ideas) is vital. And for an organization hoping for 4 or more GSoC contributors you should have at least 8-10 ideas and having them categorized is a nice touch if you have subcategories of topics within your project.
+1. Make it easy for Administrators to find your Ideas list. When reviewing many hundreds of organizations Program Admins can only spend a certain amount of time looking for your Ideas list. Many organizations are rejected because Program Admins couldn't find the actual Ideas list because the URL the org gave had a bunch of other unrelated information on it and wasn't clear where to find the actual Ideas list.
+1. Make sure to update your Project Ideas. Even if you plan to use some of the ideas that weren't chosen from a previous year at least put effort into changing the page to say 20XX Ideas list. It is not encouraging for Program Admins to see an outdated list. It also makes it seem like your project might be stale as you don't have new ideas for GSoC contributors to work on if it still shows ideas from the previous year or even two years before and is marked as such.
+1. **Never link to just a bug tracker**. This is almost always an automatic rejection. Yes, really. When Admins open the issue tracker if there is an expanded description of the project with the items listed in #1 above that is acceptable. If an org can't take the time to create a document or a page with their Ideas List fleshed out then why would Google expect they would be willing to mentor GSoC contributors for 3+ hours a week for the next 3+ months?
+1. Don't be vague about the ideas. Be sure to write a few sentences describing what you need accomplished and not just an overall theoretical version of what you might want.
+1. Be sure the URL you link to for your Ideas list works. Have someone else test it as well before you submit your application. Sometimes people don't have permissions set correctly or paste an incorrect URL which will also mean a rejection.
 
-There are many ways to define a good GSoC project--probably as many ways as there are student-mentor pairings. Here are just a few:
+There are many ways to define a good GSoC project--probably as many ways as there are GSoC contributors-mentor pairings. Here are just a few:
 
 **Low-hanging fruit**: These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals.
 
@@ -40,9 +41,9 @@ There are many ways to define a good GSoC project--probably as many ways as ther
 
 **Core development**: These projects derive from the ongoing work from the core of your development team. The list of features and bugs is never-ending, and help is always welcome.
 
-**Infrastructure/Automation**: These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC student can be really helpful, doing work that the development team has been putting off while they focus on core development.
+**Infrastructure/Automation**: These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC contributor can be really helpful, doing work that the development team has been putting off while they focus on core development.
 
-The project you propose will define the tone and scope of your organization's participation in GSoC. It is a key part of your organization's application. Further, it may be the first impression made on a potential student applicant.
+The projects you propose will define the tone and scope of your organization's participation in GSoC. It is a key part of your organization's application. Further, it may be the first impression made on a potential applicant.
 
 **Pro Tip**: Maintain an "ideas page" with a running list of entry projects year-round. This can benefit your development effort throughout the year. It can also make your organization's GSoC application easier to put together the following summer.
 
diff --git a/pages/mentor/05-selecting_a_student.md b/pages/mentor/05-selecting_a_student.md
index c0c9d0e1..307d0ac2 100644
--- a/pages/mentor/05-selecting_a_student.md
+++ b/pages/mentor/05-selecting_a_student.md
@@ -1,74 +1,77 @@
 ---
-title: Selecting a Student
+title: Selecting a GSoC contributor
 section: Getting Started
 order: 5
 permalink: mentor/selecting-a-student.html
 sidebar: mentor_sidebar
 ---
 
-Successful participation in GSoC is based on a three-way fit between mentor, student, and project. As a mentor, your role in finding that fit is two-fold: to help the organization identify and select strong students appropriate for your projects, and to find a pairing between yourself and a student that is productive and pleasant. Fortunately, these goals are quite compatible.
+Successful participation in GSoC is based on a three-way fit between the mentor(s), the GSoC contributor, and the project. As a mentor, your role in finding that fit is two-fold: to help the organization identify and select strong GSoC contributors appropriate for your projects, and to find a pairing between yourself and a GSoC contributor that is productive and pleasant. Fortunately, these goals are quite compatible.
 
+## Understanding GSoC contributor Motivations
 
-## Understanding Student Motivations
+A helpful starting point for finding, evaluating and selecting GSoC contributors is to look at the process from their point of view. Why do developers apply to GSoC?
 
-A helpful starting point for finding, evaluating and selecting students is to look at the process from their point of view. Why do students apply to GSoC?
+**"I want to be rich."** The stipend that GSoC contributors can earn for the summer is an important motivator for many.
 
-**"I want to be rich."** The stipend that students can earn for the summer is an important motivator for many. One of Google's explicit goals is to enable students to spend the summer coding "instead of flipping burgers".
+**"I want to be famous."** Being a GSoC contributor carries a certain amount of prestige. However, the desire for fame is not always a sustaining long-term motivation. Be aware of the difference between a GSoC contributor who wants to be "accepted" versus "successful".
 
-**"I want to be famous."** Being a GSoC student carries a certain amount of prestige. However, the desire for fame is not always a sustaining long-term motivation. Be aware of the difference between a student who wants to be "accepted" versus "successful".
+**"I want to learn."** GSoC contributors may want to learn various things as part of their GSoC experience, such as how to work in the organization's project, how to do open source development in general. It is important as a mentor that you are cognizant of the basic skill set required for the project.
 
-**"I want to learn."** Students may want to learn various things as part of their GSoC experience, such as how to work in the organization's project, how to do open source development in general. It is important as a mentor that you are cognizant of the basic skill set required for the project.
+GSoC contributors should want to participate because they have something to contribute to the organization's project. This is obviously an exciting and promising kind of GSoC applicant to receive. Assuming that the GSoC contributor has good technical skills and can interact well, a good result is almost inevitable.
 
-Students should want to participate because they have something to contribute to the organization's project. This is obviously an exciting and promising kind of GSoC applicant to receive. Assuming that the student has good technical skills and can interact well, a good result is almost inevitable.
+## Selecting a GSoC contributor
 
+There are some GSoC contributor qualifications that are important for any successful GSoC experience. The GSoC contributor needs to be technically skilled, needs to have good communication skills, and needs to be a hard worker with sufficient available time to succeed. Given only a brief application document and some tiny amount of remote interaction, determining whether a GSoC contributor has the necessary qualifications is exceedingly difficult. Hopefully the organization has an application process in place that helps. However, as a mentor you will normally be expected to assist in the evaluation that will ultimately decide who gets accepted to GSoC from your organization.
 
-## Selecting a Student
+You have several techniques at your disposal for helping your organization evaluate applicants. First and foremost, your expertise is key in evaluating proposals. Is a given proposal technically realistic? Is it useful to the organization? Does it meet the organization's overall goals for GSoC?
 
-There are some student qualifications that are important for any successful GSoC experience. The student needs to be technically skilled, needs to have good communication skills, and needs to be a hard worker with sufficient available time to succeed. Given only a brief application document and some tiny amount of remote interaction, determining whether a student has the necessary qualifications is exceedingly difficult. Hopefully the organization has an application process in place that helps. However, as a mentor you will normally be expected to assist in the evaluation that will ultimately decide who gets accept to GSoC from your organization.
+Check out [Tips for finding the 'right' GSoC contributor for your org](https://docs.google.com/document/d/1HrCuijYNfDZGaQ9Eyp0HQ6iXuELRmDSimrSkrJRtwug/edit?usp=sharing), compiled by mentors and org admins.
 
-You have several techniques at your disposal for helping your organization evaluate students. First and foremost, your expertise is key in evaluating student proposals. Is a given proposal technically realistic? Is it useful to the organization? Does it meet the organization's overall goals for GSoC?
+Some of the proposals your organization receives will be obvious winners, about which little discussion is needed. Many more will be obvious losers that need no discussion at all. Proposals that fail to conform to the organization submission rules, are extremely short, or are difficult to read or understand almost inevitably come from applicants who would fail miserably if accepted. The middle ground in applications is where the action is. There are several techniques for assessing these promising but troubled applications:
 
-Some of the student applications your organization receives will be obvious winners, about which little discussion is needed. Many more will be obvious losers that need no discussion at all. Applications that fail to conform to the organization submission rules, are extremely short, or are difficult to read or understand almost inevitably come from students who would fail miserably if accepted. The middle ground in student applications is where the action is. There are several techniques for assessing these promising but troubled applications:
+**Send an early query to the applicant asking for more information.** Failure to respond well or in a timely fashion almost guarantees problems with the person later on.
 
-**Send an early query to the student asking for more information.** Failure to respond well or in a timely fashion almost guarantees problems with the student later on.
+**Watch the applicant's community interaction.** The best GSoC contributors interact with your organization's community during or even well before the application period. A mediocre proposal is much less concerning if it looks like the applicant is already moving forward.
 
-**Watch the student's community interaction.** The best students interact with your organization's community during or even well before the application period. A mediocre application is much less concerning if it looks like the student is already moving forward.
+**Inquire about the applicant's GSoC history.** A GSoC contributor who has participated in GSoC before may be easy to figure out. Past performance is usually an indicator of future GSoC success. This information could be included in your organization's proposal template, or obtained from a general web search.
 
-**Inquire about the student's GSoC history.** A student who has participated in GSoC before may be easy to figure out. Past performance is usually an indicator of future GSoC success. This information could be included in your organization's student application template, or obtained from a general web search.
-
-**Find out where else the student has applied.** Does the student have other GSoC applications? Did they copy-paste the same application over and over? There are often opportunities for negotiation with other organizations around a student who has applied to several places.
-
-**Look at the student's other summer plans.** A student who at least claims to be solely focused on GSoC is more likely to be successful.
+**Find out where else the applicant has applied.** Does the applicant have other GSoC proposals? Did they copy-paste the same proposal over and over? There are often opportunities for negotiation with other organizations around someone who has applied to several places.
 
+**Look at the applicant's other summer plans.** You are looking for an applicant who is up front about possible other commitments during GSoC. If they have other commitments and are planning to do a 350 hour project in 12 weeks that could be a concern. However, if they are doing a 175 hour project in 12 weeks and are taking a class or have another part-time commitment it could likely be fine. With the 90 hour projects it is much easier to be able to have a GSoC contributor who does not become overwheled with managaing a couple of classes during GSoC.
 
 ## Finding a Match
 
-As a mentor you want to do more than just help your organization select the best students. You also want to ensure that they select a student and project that you will enjoy working with.
-
-This may involve more than just finding a bright student with the right area of expertise. It is worthwhile to look at the personality type and work style a student application reflects. If you are a methodical, organized person, for example, a loose and casual student style might not be an ideal fit for you. Mentoring a student geographically far from you can be a bit challenging, but also quite enlightening. Be aware of timezone differences that might require early morning or late night schedules for live meetings, which are critical for effective mentoring.
+As a mentor you want to do more than just help your organization select the best GSoC contributor. You also want to ensure that they select a GSoC contributor and project that you will enjoy working with.
 
-For those unfortunate students that don't make the cut for logistical reasons (e.g., not enough mentors or funded slots), consider providing feedback to let them know their applications were valued.  This is a service both to the student and to the organization. These students will be more likely to stay engaged, possibly even contributing outside of the official GSoC program, and returning next year with an even stronger application.
+This may involve more than just finding a bright GSoC contributor with the right area of expertise. It is worthwhile to look at the personality type and work style a proposal reflects. If you are a methodical, organized person, for example, a loose and casual style might not be an ideal fit for you. Mentoring a GSoC contributor geographically far from you can be a bit challenging, but also quite enlightening. Be aware of timezone differences that might require early morning or late night schedules for live meetings, which are critical for effective mentoring.
 
+For those unfortunate applicants that don't make the cut for logistical reasons (e.g., not enough mentors or funded slots), consider providing feedback to let them know their proposals were valued.  This is a service both to the applicant and to the organization. These applicants will be more likely to stay engaged, possibly even contributing outside of the official GSoC program, and returning next year with an even stronger proposal.
 
 ## Google's Selection Process
 
-The Google Open Source Program Office (OSPO) has an internal process to select mentoring organizations and allocate GSoC student slots; understanding it may help you make better student selections.
+The Google Open Source Program Office (OSPO) has an internal process to select mentoring organizations and allocate GSoC contributor slots; understanding it may help you make better GSoC contributor selections.
 
-Each mentoring organization will review the applications they receive (outside of the program site) and determine the best projects using the criteria agreed upon by their organization. Next the Org Admins will make sure those "best projects" have at least one mentor confirmed to mentor that project. Then the Org Admin will enter a minimum and a maximum number of student "slots" they wish to receive. The minimum is based on the projects that are so amazing they really want to see these projects occur over the summer and the maximum number should be the number of solid and amazing projects they wish to mentor over the summer.
+Each mentoring organization will review the applications they receive (outside of the program site) and determine the best projects using the criteria agreed upon by their organization. Next the Org Admins will make sure those "best projects" have at least one mentor confirmed to mentor that project. Then the Org Admin will rank the proposals with confirmed mentors using the organization's agreed upon criteria. (Note: Google is looking for a mixture of medium and large projects, not just large projects from an org when possible). If your org has 10 great contributors and you rank the 7 large projects 1-7, then the 3 medium projects as 8-10 be prepared to get less slots than if you had mixed up medium and large in the top 7. If you have some small (90 hour) projects mixed in you'll also be likely to receive more slots. Next the Org Admin will submit the ranked GSoC contributor "slots" they wish to receive.
 
-Next, Google OSPO will allocate each organization a number of student slots. It is then up to the Org admins and mentors to decide which of their student proposals will become their organization's accepted student slots. The Org Admin will then select the student proposals on the program site.
+Next, Google OSPO will allocate each organization a number of slots. The number of slots will lock in the top ranked proposals for the organization. If an organization received 5 slots then their #1-#5 ranked proposals will automatically become GSoC contributor projects.
 
-You should also understand how student selection and mentoring can affect the eligibility of an organization. In particular, note that a poor job of mentoring may lead to a poor outcome, making it less likely that your organization will be selected in future years. But failing a student does not mean that Google will consider that organization poorly for future programs, we encourage organizations to fail if the student is not doing the work, generally 12-15% of students fail their project in a given year at some point in the program.
+Google will let organizations know how many slots they receive a day or two before we announce the accepted projects publicly so organizations and mentors can prepare.
 
+You should also understand how GSoC contributor selection and mentoring can affect the eligibility of an organization. In particular, note that a poor job of mentoring may lead to a poor outcome, making it less likely that your organization will be selected in future years. But failing a GSoC contributor does not mean that Google will consider that organization poorly for future programs, we encourage organizations to fail if the GSoC contributor is not doing the work, historically 8-15% of students fail or withdraw from the program in a given year.
 
 ## Starting at the Beginning
 
-A successful GSoC project begins with a successful initiation. Finding the right three-way fit between mentor, student and organization can make success incredibly easy. Conversely, failing to find this fit makes it difficult or impossible for the project to succeed.
+A successful GSoC project begins with a successful initiation. Finding the right three-way fit between mentor, GSoC contributor and organization can make success incredibly easy. Conversely, failing to find this fit makes it difficult or impossible for the project to succeed.
+
+Once a fit is found, the project is ready to be elaborated. You and your GSoC contributor are prepared to embark upon a grand adventure. Excelsior!
+
+**Pro Tip**: One temptation to be avoided is to give a promising GSoC contributor excessive help in rewriting their proposal. It is likely that the result will be a proposal stronger than the GSoC contributor it represents. A GSoC contributor's communication, organization and logical thinking skills rarely improve over the course of a summer.
 
-Once a fit is found, the project is ready to be elaborated. You and your student are prepared to embark upon a grand adventure. Excelsior!
+**Pro Tip**: If in doubt about an applicant's final ranking, err on the side of rejecting. Limited program budget and mentor time can most certainly be better spent on another applicant in your or another organization.
 
-**Pro Tip**: One temptation to be avoided is to give a promising student excessive help in rewriting their proposal. It is likely that the result will be a proposal stronger than the student it represents. Students' communication, organization and logical thinking skills rarely improve over the course of a summer.
+**Don't Be That Person**: Don't even think about selecting a GSoC contributor with whom you've had no contact. You should establish an active back-and-forth prior to making a decision. If you or your GSoC contributor have failed to make this happen, *do not proceed*.
 
-**Pro Tip**: If in doubt about a student applicant's final ranking after allocation, err on the side of rejecting. Limited program budget and mentor time can most certainly be better spent on another student in your or another organization.
+**Don't select multiple people for the same project idea**: If two GSoC contributors are working on the exact same project then they are competing with each other. Likewise, don't make one person's project dependent on another person's project, that essentially makes it a team project which is not allowed or in the best interest of the GSoC contributors.
 
-**Don't Be That Person**: Don't even think about selecting a student with whom you've had no contact. You should establish an active back-and-forth prior to making a decision. If you or your student have failed to make this happen, *do not proceed*.
+**Don't select a GSoC contributor based solely on their proposal**: Anyone can write a good proposal, in fact multiple people have created videos on how to create an amazing GSoC proposal. You want to pick someone that is a good fit for your community and asks great questions. They don't have to be the most knowledgeable to be a great candidate. If they want to learn and have taken the time to read through your documentation to understand your community and have reached out to your community they are much more likely to be a successful GSoC (and open source) contributor.
diff --git a/pages/mentor/06-community_basics.md b/pages/mentor/06-community_basics.md
index 23a70b07..f51786c3 100644
--- a/pages/mentor/06-community_basics.md
+++ b/pages/mentor/06-community_basics.md
@@ -6,27 +6,22 @@ permalink: mentor/community-basics.html
 sidebar: mentor_sidebar
 ---
 
-Your community is the collection of people who work on or with your project. Helping your student become familiar with those people makes them a more effective contributor during GSoC and helps to make them feel part of your community, which encourages involvement after their GSoC project is completed.
-
+Your community is the collection of people who work on or with your project. Helping your GSoC contributor become familiar with those people makes them a more effective contributor during GSoC and helps to make them feel part of your community, which encourages involvement after their GSoC project is completed.
 
 ## Set the Tone
 
-As a mentor, you can really help to set the tone for your student's initial experiences by facilitating community. Encourage your student to introduce themselves on mailing lists and IRC, and invite comments on their proposal. If your project maintains biographical information on contributors, ask your student to read through this information, and spend some time talking with your student about the people with whom they may interact.
-
-Once a student has a feeling for who's who in the community, they are more likely to communicate and seek advice from others. This increases their chances of getting issues resolved more quickly and effectively than if they relied on only their mentor for help.
+As a mentor, you can really help to set the tone for your GSoC contributors's initial experiences by facilitating community. Encourage your GSoC contributor to introduce themselves on mailing lists and chat, and invite comments on their proposal. If your project maintains biographical information on contributors, ask your GSoC contributor to read through this information, and spend some time talking with your student about the people with whom they may interact.
 
+Once a GSoC contributor has a feeling for who's who in the community, they are more likely to communicate and seek advice from others. This increases their chances of getting issues resolved more quickly and effectively than if they relied on only their mentor for help.
 
 ## Encourage Questions
 
 Asking effective questions is a skill, not an innate talent. There are many resources for learning how to ask questions effectively, and Eric Raymond's classic [How to ask good questions](http://catb.org/~esr/faqs/smart-questions.html) is a great place for students to start.  Another useful resource is Simon Tatham's [How to Report Bugs Effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) which isn't explicitly about asking questions, but does cover aspects of effective communication about technical issues.
 
-Before your student asks a question, it's often helpful for them to take a minute to struggle with it and attempt to find the answer on their own. That extra effort often helps your student to solve their own problem. If not, it sharpens the question they ultimately ask.
-
+Before your GSoC contributor asks a question, it's often helpful for them to take a minute to struggle with it and attempt to find the answer on their own. That extra effort often helps your GSoC contributor to solve their own problem. If not, it sharpens the question they ultimately ask.
 
 ## Criticism Happens
 
-Discussion in open source communities can be very direct. People will often criticize the bad points of a patch or suggestion, but fail to praise what is good about it. Explain to the student that comments aren't meant to be critical of them as a person, but are aimed toward improving the patch or idea and the project in general. Making potential new contributors feel welcome in your community is also important outside of GSoC.
-
-**Pro Tip**: When you announce to the community that you're taking part in GSoC, make a point of explicitly asking people to make the students feel welcome.
-
+Discussion in open source communities can be very direct. People will often criticize the bad points of a patch or suggestion, but fail to praise what is good about it. Explain to the GSoC contributors that comments aren't meant to be critical of them as a person, but are aimed toward improving the patch or idea and the project in general. Making potential new contributors feel welcome in your community is also important outside of GSoC.
 
+**Pro Tip**: When you announce to the community that you're taking part in GSoC, make a point of explicitly asking people to make the GSoC contributors feel welcome.
diff --git a/pages/mentor/07-best_practices.md b/pages/mentor/07-best_practices.md
index 53e1e772..52c34796 100644
--- a/pages/mentor/07-best_practices.md
+++ b/pages/mentor/07-best_practices.md
@@ -6,69 +6,66 @@ permalink: mentor/best-practices.html
 sidebar: mentor_sidebar
 ---
 
-Effective communication between mentor and student is absolutely vital to a successful and rewarding GSoC experience. Here are some tips for encouraging good communication:
+Effective communication between mentor and GSoC contributor is absolutely vital to a successful and rewarding GSoC experience. Here are some tips for encouraging good communication:
 
-**Share contact details**: Swap contact information with your student and org admin early on. If your contact information changes, be sure to tell people, and make sure your student does too. Be sure to keep the org admin informed about when you may be unavailable to your student, so that they are not caught unaware when your student contacts them.
+**Share contact details**: Swap contact information with your GSoC contributor and org admin early on. If your contact information changes, be sure to tell people, and make sure your GSoC contributor does too. Be sure to keep the org admin informed about when you may be unavailable to your GSoC contributor, so that they are not caught unaware when your GSoC contributor contacts them.
 
-You need to take care if you are planning a trip during the summer, especially if it is more than a few days, or near milestones in the GSoC timeline. If you coordinate with your student beforehand and give them sufficient work to chew on, it can go smoothly. What you don't want is for your student to be blocked on something while you are inaccessible and do nothing until you return. Make sure to give your student many different tasks to work on, so that she can work on something else if you are not available. This is a great time to utilize a secondary mentor to act as a backup in your absence.
+You need to take care if you are planning a trip during the summer, especially if it is more than a few days, or near milestones in the GSoC timeline. If you coordinate with your GSoC contributor beforehand and give them sufficient work to chew on, it can go smoothly. What you don't want is for your GSoC contributor to be blocked on something while you are inaccessible and do nothing until you return. Make sure to give your GSoC contributor many different tasks to work on, so that they can work on something else if you are not available. This is a great time to utilize a secondary mentor to act as a backup in your absence. Be sure another mentor (or org admin) is available to complete the evaluation if you're unavailable.
 
-**Choose communication channels**: Decide upfront how you are going to communicate with your student and what type of technology or medium you are going to use. Don't wait until mid-way through GSoC to figure out that one of you can't get your microphone working on your desktop for voice chat.
+**Choose communication channels**: Decide upfront how you are going to communicate with your GSoC contributor and what type of technology or medium you are going to use. Don't wait until mid-way through GSoC to figure out that one of you can't get your microphone working on your desktop for voice chat.
 
 It's good to make use of multiple means of communication, as different platforms can complement each other. Instant methods like IRC or IM or Slack channels are great for getting a quick answer or for interactive discussion, but require both parties to be available at once. Public communications are generally preferable to private ones.
 
-Although many people prefer text-only communication, it is very helpful to talk on the phone or video-chat with your student at least once at the beginning of the program. Hearing a voice or seeing a face can help people feel more connected, creating a sense of mutual respect and responsibility.
+Although some people prefer text-only communication, it is very helpful to talk on the phone or video-chat with your GSoC contributor at least once at the beginning of the program and again midway through. Hearing a voice or seeing a face can help people feel more connected, creating a sense of mutual respect and responsibility. Feedback from GSoC contributors has made it clear they really enjoy having weekly or bi-weekly video chats with their mentors or community members.
 
-**Decide on the frequency of reports**: Discuss and decide the frequency and form of status reports upfront. Many organizations require students to deliver weekly status reports, some require daily reports. Make sure you clearly delineate in what format the reports should be delivered and what information needs to be included.  Providing an outline or template can be helpful**.**
+**Decide on the frequency of reports**: Discuss and decide the frequency and form of status reports upfront. Many organizations require GSoC contributors to deliver weekly status reports, some require daily reports. Do not wait until the midterm to get a status report, that never ends well. Make sure you clearly delineate in what format the reports should be delivered and what information needs to be included.  Providing an outline or template can be helpful.
 
-**Establish frequent chatter**: You really want to be hearing from your student more often than once a week, as this is a long time for a student to be stuck or heading up a blind alley. Be sure to encourage and instigate communication throughout the week.
+**Establish frequent chatter**: You really want to be hearing from your GSoC contributor more often than once a week, as this is a long time for a GSoC contributor to be stuck or heading up a blind alley. Be sure to encourage and instigate communication throughout the week.
 
-**Provide a safe environment**: Create an environment in which your student feels comfortable enough to ask questions that may sound "stupid". This will help the student to avoid getting stuck, and foster positive mentor-student and student-community relationships. Good relationships are extremely important for GSoC success, and for fostering and encouraging long-term contributors.
+**Provide a safe environment**: Create an environment in which your GSoC contributor feels comfortable enough to ask questions that may sound "stupid". This will help the GSoC contributor to avoid getting stuck, and foster positive mentor-GSoC contributor and GSoC contributor-community relationships. Good relationships are extremely important for GSoC success, and for fostering and encouraging long-term contributors.
 
-Here are some ways to help your student understand that her question is valuable:
+Here are some ways to help your GSoC contributor understand that her question is valuable:
 
-**Avoid gruff "RTFM" replies**: It's likely the student will ask questions which are answered somewhere in your project's documentation. However, do take a few moments extra to politely point to the information, or you'll risk the student feeling reluctant to ask next time he has a question.
+**Avoid gruff "RTFM" replies**: It's likely the GSoC contributor will ask questions which are answered somewhere in your project's documentation. However, do take a few moments extra to politely point to the information, or you'll risk the GSoC contributor feeling reluctant to ask next time they have a question.
 
-**Ask some stupid questions yourself**: Chances are your student knows some things you don't know or that you've just forgotten. Don't be afraid to ask your student questions.
+**Ask some stupid questions yourself**: Chances are your GSoC contributor knows some things you don't know or that you've just forgotten. Don't be afraid to ask your GSoC contributor questions.
 
-**Be inclusive**: If you're asked a question which someone else in your project could answer better, put your student in touch with them. Invite your student to participate in your community events, not just the core development processes. Invite your student to attend group retreats or related conferences.
+**Be inclusive**: If you're asked a question which someone else in your project could answer better, put your GSoC contributor in touch with them. Invite your GSoC contributor to participate in your community events, not just the core development processes. Invite your GSoC contributor to attend group retreats or related conferences.
 
-**Introduce your student to the community's communication style**: Many groups have developed codes of conduct, such as the [Fedora IRC Helpers Code of Conduct](http://fedoraproject.org/wiki/IRC_helpers_code_of_conduct), which help initiate new members and guide the interactions of existing members. You are encouraged to read the code of conduct and think about which issues and solutions might apply to your group. Please also check out [Google's Community guidelines](https://opensource.google/conduct/).
+**Introduce your GSoC contributor to the community's communication style**: Many groups have developed codes of conduct, such as the [Fedora IRC Helpers Code of Conduct](http://fedoraproject.org/wiki/IRC_helpers_code_of_conduct), which help initiate new members and guide the interactions of existing members. You are encouraged to read the code of conduct and think about which issues and solutions might apply to your group. Please also check out [Google's Community guidelines](https://opensource.google/conduct/).
 
-**Follow mailing list etiquette**: The GSoC mentors mailing list has more than 9000 subscribers. If you have a question for the Google team, mail gsoc-support@google.com instead of the list. Please take a moment to review list [etiquette](https://www.google.com/search?q=mailing+list+etiquette).
+**Follow mailing list etiquette**: The GSoC mentors mailing list has more than 16000 subscribers. If you have a question for the Google team, mail <gsoc-support.com> instead of the list. Please take a moment to review list [etiquette](https://www.google.com/search?q=mailing+list+etiquette).
 
-**Address communication disconnects**: When working with people for the first time, a best practice is to assume that they do not mean any harm. If your student makes a comment via email that offends another member of the community, it's appropriate and constructive to speak up and address the issue. Assuming that the comment was the result of misunderstanding, rather a result of malice, allows you to ask questions and help your student adjust to your community's communication style.
+**Address communication disconnects**: When working with people for the first time, a best practice is to assume that they do not mean any harm. If your GSoC contributor makes a comment via email that offends another member of the community, it's appropriate and constructive to speak up and address the issue. Assuming that the comment was the result of misunderstanding, rather a result of malice, allows you to ask questions and help your GSoC contributor adjust to your community's communication style.
 
-After asking questions, you can then offer an explanation to a person or a suggestion on how they could behave or phrase their comments differently in the future. When offering coaching on how to behave, be mindful of embarrassing your student in public about what's happened, or demanding apologies. If possible, talk to your student one on one, using an immediate communication medium like IM, IRC, the telephone or a face-to-face conversation. This is better than sending email. Remember that you're telling someone that they did something wrong; keep in mind how you'd feel if someone was telling you that you'd made a mistake.
+After asking questions, you can then offer an explanation to a person or a suggestion on how they could behave or phrase their comments differently in the future. When offering coaching on how to behave, be mindful of embarrassing your GSoC contributor in public about what's happened, or demanding apologies. If possible, talk to your GSoC contributor one on one, using an immediate communication medium like IM, IRC, the telephone or a face-to-face conversation. This is better than sending email. Remember that you're telling someone that they did something wrong; keep in mind how you'd feel if someone was telling you that you'd made a mistake.
 
-**Apologize Effectively**: Making apologies is a fact of human life, and open source communities are no exception. In the event that you or a student finds themselves needing to make an apology, there are a few things that might help you apologize effectively:
-
-*   Make the apology as soon as possible
-*   Make it clear in the subject line that you're apologizing
-*   Make it an honest apology and not a defensive statement in disguise
+**Apologize Effectively**: Making apologies is a fact of human life, and open source communities are no exception. In the event that you or a GSoC contributor finds themselves needing to make an apology, there are a few things that might help you apologize effectively:
 
+* Make the apology as soon as possible
+* Make it clear in the subject line that you're apologizing
+* Make it an honest apology and not a defensive statement in disguise
 
 ## Giving and Receiving Criticism
 
-Mailing list culture and public code review can be a rude awakening for newcomers. Submitting a patch to a mailing list might be a student's first experience with public critique of their code.
+Mailing list culture and public code review can be a rude awakening for newcomers. Submitting a patch to a mailing list might be a GSoC contributor's first experience with public critique of their code.
 
 Project policies vary widely on how contributions are treated. Some encourage committing early and often, hopefully maintaining a stable branch for bug-fixes. Others refuse to commit code to the core repository until a patch is fully discussed, tested and documented. Most projects lie somewhere in between.
 
 All projects engage in some form of code review and the inevitable criticism. Having people look at and ask questions about your code is a fact of working in the open source world. Direct code review is one of the great strengths of open source development. Direct review helps people hone their coding skills and learn rapidly from others. Bugs are found quickly and fixed. The whole process is documented in source control repositories and mailing lists and made available online.
 
-Here are some ways that you can help students prepare for code review:
+Here are some ways that you can help GSoC contributors prepare for code review:
 
-*   Provide example mailing list threads or a list of the types of questions that are asked about code.
-*   Direct students to review coding standards that apply to your project.
-*   Go through an example code review on the student's first code sample submission that matches as closely as possible the process that your project normally uses.
+* Provide example mailing list threads or a list of the types of questions that are asked about code.
+* Direct GSoC contributors to review coding standards that apply to your project.
+* Go through an example code review on the GSoC contributor's first code sample submission that matches as closely as possible the process that your project normally uses.
 
-People are more likely to respond positively to criticism from those that they trust and respect. Try introducing students to the people that are likely to comment on their code, and explaining the role that those people play in the group. Also, encourage students to both defend technical decisions, and be gracious in admitting mistakes.
+People are more likely to respond positively to criticism from those that they trust and respect. Try introducing GSoC contributors to the people that are likely to comment on their code, and explaining the role that those people play in the group. Also, encourage GSoC contributors to both defend technical decisions, and be gracious in admitting mistakes.
 
-Code, in addition to being mathematical and scientific, has been compared to poetry or creative writing. Most developers associate a sense of ownership and creative discovery with their code. You may have "gotten over" the bruised ego you received the first time that someone criticized your variable name or algorithm choice. However, your student may be experiencing this pain for the first time. A simple "thank you" when students publish code, send email to a mailing list or make other contributions goes a long way.
+Code, in addition to being mathematical and scientific, has been compared to poetry or creative writing. Most developers associate a sense of ownership and creative discovery with their code. You may have "gotten over" the bruised ego you received the first time that someone criticized your variable name or algorithm choice. However, your GSoC contributor may be experiencing this pain for the first time. A simple "thank you" when GSoC contributors publish code, send email to a mailing list or make other contributions goes a long way.
 
-Make an effort to assist a student in their first steps into your community. Offer to proofread emails, blog posts, or patches. You don't want to do all the work for them, but you can help students feel confident in their communication, especially when they're just starting out.
+Make an effort to assist a GSoC contributor in their first steps into your community. Offer to proofread emails, blog posts, or patches. You don't want to do all the work for them, but you can help GSoC contributors feel confident in their communication, especially when they're just starting out.
 
 **Pro Tip**: A good status report should include a few items that went well during the previous period, and a few problems that were encountered and how they were addressed.
 
-**Don't Be That Person**: Don't ever give your student the impression that you think that only stupid people ask questions.  Be nice.  Remember that you were once a beginner.
-
-
+**Don't Be That Person**: Don't ever give your GSoC contributor the impression that you think that only stupid people ask questions.  Be nice.  Remember that you were once a beginner.
diff --git a/pages/mentor/08-warning_signs.md b/pages/mentor/08-warning_signs.md
index 35d14c30..c27bec45 100644
--- a/pages/mentor/08-warning_signs.md
+++ b/pages/mentor/08-warning_signs.md
@@ -8,31 +8,28 @@ sidebar: mentor_sidebar
 
 As a GSoC mentor, you are in the best position to identify "red flags" and warning signs early on. This is critical to addressing problems before they get out of hand. Learn from the mistakes of others, and learn how to identify and mitigate the following warning signs.
 
-**Not enough hours in the day**: If your student has a full-time job or is attempting to defend a graduate thesis during the summer, that is probably going to not work. Even though your student thinks they will have enough extra time, don't believe them. They won't. If your student has every single minute of every day completely booked, any unexpected event, such as getting sick or a family emergency, derails this plan beyond repair. If your student cannot commit to a specified time schedule, this is an immediate red flag that they need serious help with time management.
+**Not enough hours in the day**: If your GSoC contributor has a full-time job or is attempting to defend a graduate thesis during the summer, that is probably going to not work if they are trying to do a 350 hour project. Even though your GSoC contributor thinks they will have enough extra time, don't believe them. They won't. If your GSoC contributor has every single minute of every day completely booked, any unexpected event, such as getting sick or a family emergency, derails this plan beyond repair. If your GSoC contributor cannot commit to a specified time schedule, this is an immediate red flag that they need serious help with time management.
 
-**Missing student**:  Missing a predefined meeting is a serious warning sign that your student is not taking the process seriously and this should be remedied as early as possible.  If your student was in such a deep "coding zone" that they forget the meeting, and you have it later on, that might be acceptable.
+**Missing GSoC contributor**:  Missing a predefined meeting is a serious warning sign that your GSoC contributor is not taking the process seriously and this should be remedied as early as possible.  If your GSoC contributor was in such a deep "coding zone" that they forget the meeting, and you have it later on, that might be acceptable.
 
-**"My village was invaded by aliens"**: What is a valid excuse? Students have been known to come up with outlandish excuses as to why they are not meeting their milestones. *(You did agree on milestones beforehand, right?)* If you think that your student is lying to you, that is a huge warning that things are going sour. Make sure to remind them that "real life just got in the way, I will redouble my efforts next week" is always better than "my village was invaded by aliens."
-
-**Bad students happen to good mentors**: One thing to keep in mind: *Sometimes bad students happen to good mentors.* Don't take it personally. If a mentor tries their hardest and their student fails, this does not reflect badly on the mentor.
+**"My village was invaded by aliens"**: What is a valid excuse? GSoC contributors have been known to come up with outlandish excuses as to why they are not meeting their milestones. *(You did agree on milestones beforehand, right?)* If you think that your GSoC contributor is lying to you, that is a huge warning that things are going sour. Make sure to remind them that "real life just got in the way, I will redouble my efforts next week" is always better than "my village was invaded by aliens."
 
+**Bad GSoC contributors happen to good mentors**: One thing to keep in mind: *Sometimes bad GSoC contributors happen to good mentors.* Don't take it personally. If a mentor tries their hardest and their GSoC contributor fails, this does not reflect badly on the mentor.
 
 ## "Actions Speak Louder Than Words"
 
-This bit of folk wisdom is proven year after year during GSoC. A mentor will write to the mentors mailing list asking for advice about a student that has not performed or gone missing for a period of time. Mid-term evaluations are coming up and the student has reappeared, reinvigorated, with no shortage of excuses. Now the mentor must decide: "Should I pass this student?".
+This bit of folk wisdom is proven year after year during GSoC. A mentor will write to the mentors mailing list asking for advice about a GSoC contributor that has not performed or has gone missing for a period of time. Mid-term evaluations are coming up and the GSoC contributor has reappeared, reinvigorated, with no shortage of excuses. Now the mentor must decide: "Should I pass this GSoC contributor?".
 
-The GSoC mailing list contains story after story from other mentors who ignored the warning signs, only to be disappointed later.  A mentor considers this advice, but focuses on the unique aspects of their particular situation and passes the student...and their story is added to the list the following year.
+The GSoC mailing list contains story after story from other mentors who ignored the warning signs, only to be disappointed later.  A mentor considers this advice, but focuses on the unique aspects of their particular situation and passes the GSoC contributor...and their story is added to the list the following year.
 
 Here are some specific scenarios to watch out for:
 
-**The Disappearing Student**: A student submits a great proposal and is enthusiastic about discussing the project and getting started. You rank them high, they get accepted, and then they drop off the face of the earth. **Fail.**
-
-**Underperformance**: The student sticks around for the community bonding period, but then it comes time to work. When it comes to actually writing code, they seriously under perform. They offer excuses when pressed, and offer scraps of code here and there. Then comes the mid-term evaluation and start committing like crazy. **Fail.**
-
-**Wrong Priorities**: The student passes the mid-term and then goes on an unscheduled holiday for two weeks or starts a part-time job and the quality or quantity of work is seriously affected. You discuss this with them immediately and they promise to reprioritize, but the work is not produced. **Fail.**
+**The Disappearing GSoC contributor**: A GSoC contributor submits a great proposal and is enthusiastic about discussing the project and getting started. You rank them high, they get accepted, and then they drop off the face of the earth. **Fail.**
 
-Depending on your personality type, some of these might seem harsh. You might also shoulder some of the blame because you think that if you had been a better mentor, more on top of the situation, it would have been avoided. But even if you are partly to blame, so is the student. And it is up to the student to perform when expectations are communicated and agreed upon.
+**Underperformance**: The GSoC contributor sticks around for the community bonding period, but then it comes time to work. When it comes to actually writing code, they seriously under perform. They offer excuses when pressed, and offer scraps of code here and there. Then comes the mid-term evaluation and they start committing like crazy. **Fail.**
 
-**Pro Tip**: In the event your student's boat is sinking, all mentors are equipped with emergency rocket-propelled jet skis.
+**Wrong Priorities**: The GSoC contributor passes the mid-term and then goes on an unscheduled holiday for two weeks or starts a part-time job and the quality or quantity of work is seriously affected. You discuss this with them immediately and they promise to reprioritize, but the work is not produced. **Fail.**
 
+Depending on your personality type, some of these might seem harsh. You might also shoulder some of the blame because you think that if you had been a better mentor, more on top of the situation, it would have been avoided. But even if you are partly to blame, so is the GSoC contributor. And it is up to the GSoC contributor to perform when expectations are communicated and agreed upon.
 
+**Pro Tip**: In the event your GSoC contributor's boat is sinking, all mentors are equipped with emergency rocket-propelled jet skis.
diff --git a/pages/mentor/09-open_source_culture.md b/pages/mentor/09-open_source_culture.md
index 0e11bfc0..ab5fc1f4 100644
--- a/pages/mentor/09-open_source_culture.md
+++ b/pages/mentor/09-open_source_culture.md
@@ -8,7 +8,6 @@ sidebar: mentor_sidebar
 
 When you encounter an open source group for the first time, it may be a bewildering experience. Whether posting to a mailing list for the first time, blogging about the project you're taking on or hanging out on an IRC channel - the way people interact, and what they expect from each other is pretty different than in classroom or with friends and family.
 
-
 ## Openness and Sharing
 
 Open source communication can vary a lot. A core value held in common is that sharing code is good. Regardless of license, language or indentation style, open source developers create, share and modify source code together.
@@ -21,7 +20,6 @@ One aspect of "open culture" is that people are informal. People address each ot
 
 Although "open culture" is generally informal, it is important to remember that you still need to mind your manners when participating in conversations.
 
-
 ## Remote Communication
 
 Many projects involve individuals who are working not only in different cities, countries and continents, but collaborating across major cultural and language differences. And rather than having procedures or policies on how to interact with one another handed down from HR departments or other authorities, communication practices evolve between individuals over time.
@@ -32,36 +30,32 @@ Be mindful of cultural assumptions about race, gender, sexual orientation and di
 
 All that tolerant rhetoric aside, it is never productive for an open source project to allow individuals who consistently try to cause harm to others to do so. If you are causing undue problems don't be surprised if you are asked to discontinue your participation regardless of your contributions. It's often better for an open source project to ask someone to leave, than to allow them to harm others and in turn, cause other productive members of your team to depart.
 
-
 ## Abbreviations and Slang
 
 People come up with abbreviations and slang that are meaningful inside the group, but not necessarily to outsiders. Ask questions when you don't understand a term, a joke or some arcane bit of project lore.
 
 Here are a few useful resources for teasing out meaning from initialisms, acronyms and abbreviations:
 
-*   Urban Dictionary (<http://www.urbandictionary.com>)
-*   Webster's Online Dictionary (<http://www.websters-online-dictionary.org/>)
-*   Acronym Finder (<http://www.acronymfinder.com/>)
-*   A to Z word finder (<http://www.a2zwordfinder.com/>)
-
+* Urban Dictionary (<http://www.urbandictionary.com>)
+* Webster's Online Dictionary (<http://www.websters-online-dictionary.org/>)
+* Acronym Finder (<http://www.acronymfinder.com/>)
+* A to Z word finder (<http://www.a2zwordfinder.com/>)
 
 ## Volunteerism and Gift Economies
 
-Donated time are the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple "thank you" in return.
+Donated time is the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple "thank you" in return.
 
 Contributions to projects are often self-directed, with developers having a personal itch to scratch in the form of a new feature, by correcting a bug that they've encountered or by implementing something from a TODO list. Projects operating in this way may seem chaotic if you are only familiar with top-down management - where teachers, professors or bosses tell you what to do and when. Of course, some projects do have clearly defined project management, with milestones and tasks meted out carefully.
 
 Because many (or in some cases all) contributors are volunteering, methods of coercion available to businesses are not available. The best way to collaborate is to behave in a way that encourages others, and ultimately, makes people want to contribute. Some easy ways to encourage volunteerism include:
 
-*   Saying thank you
-*   Giving compliments when they are deserved, regularly and in public
-*   Publicizing cool hacks and features as they are implemented, in blog posts and on the mailing lists
-*   Promptly committing useful code
-*   Responding promptly to requests for information
-*   Clearly defining ways to contribute to your project (TODO lists are great!)
+* Saying thank you
+* Giving compliments when they are deserved, regularly and in public
+* Publicizing cool hacks and features as they are implemented, in blog posts and on the mailing lists
+* Promptly committing useful code
+* Responding promptly to requests for information
+* Clearly defining ways to contribute to your project (TODO lists are great!)
 
 Consider treating every patch like it is a gift. Being grateful is good for both the giver and the receiver, and invigorates the cycle of virtuous giving.
 
 Overall, your goal is to help create and maintain an atmosphere around contribution that is enjoyable. What that means will vary significantly depending on the project, but certainly the above points apply to any project.
-
-
diff --git a/pages/mentor/10-community_bonding_period.md b/pages/mentor/10-community_bonding_period.md
new file mode 100644
index 00000000..9f85b82c
--- /dev/null
+++ b/pages/mentor/10-community_bonding_period.md
@@ -0,0 +1,30 @@
+---
+title: Community Bonding Period
+section: Mentoring
+order: 10
+permalink: mentor/community-bonding-period.html
+sidebar: mentor_sidebar
+---
+
+The community bonding period is the 3 weeks between GSoC contributor acceptance and the start of coding date. This is a vital time to engage with your GSoC contributor and set them up for success. Feedback from some GSoC contributors in recent years has been that their mentors and organizations didn't do anything in the community bonding period and they didn't understand what they should have been doing. The Community Bonding Period is the organization's opportunity to set expectations and milestones, welcome the contributor to their community and give the GSoC contributor access to the tools they need to succeed during the coding period.
+
+Many orgs are not using the community bonding constructively - this is direct feedback from a number of GSoC contributors. Remember, the GSoC contributor is excited to start getting involved with your community, welcome them in immediately!
+
+Here are some of the goals of this period:
+
+* Prepare GSoC contributors to immediately start writing code at the official start of coding.
+* Get GSoC contributor engaged socially in the project. GSoC contributors have given very positive feedback about orgs that have had welcome video calls with the community. Having all of your GSoC contributors and mentors on the same call is a big plus for everyone. And bonus if you have a previous GSoC contributor that is still active in your community join the call to briefly chat about their experience.
+* Provide time for GSoC contributors to learn about the development practices of the organization.
+* Ensure that GSoC contributors have a development environment set up. This includes getting set up with the project version control system and reading up on necessary documentation.
+* Further refine the strategic plan for project completion. Be sure to have solid requirements for both phases particularly the end of the first phase so there is no confusion between your expectations and the GSoC contributor's. Other milestones for the final phase can be adjusted by discussing with the GSoC contributor as needed.
+* This is a time for the GSoC contributor to get required forms filled out, such as the tax forms required by Google, any contributor license agreements, and any paperwork that your project requires.
+
+This period was added in 2007 to help GSoC contributors integrate with their development community and so encourage them to become lifetime contributors. New contributors to a project outside of GSoC often lurk in a project's chat channel and/or mailing lists for weeks or months before submitting their first patch. The community bonding period is an attempt to improve that experience.
+
+Successful completion of your GSoC contributor's GSoC project depends a lot on the bonding period. Make sure that you and your GSoC contributor make good use of this time and make significant progress on preliminary tasks. The community bonding period is also a good chance for the GSoC contributors to start interacting with each other. Early connections can help the GSoC contributors support each other during coding.
+
+Ideally GSoC contributors are ready to start writing code at the official start of coding, and are already engaged socially. During the community bonding period GSoC contributors are expected to learn about the development processes of their organization, ensure they have a development environment set up, get set up with the project version control system, read up on necessary documentation, and further refine the strategic plan for successful project completion.
+
+Plan weekly activities for your GSoC contributor that only take an hour or two.
+
+**Pro Tip**: GSoC contributors are meant to be "in good standing with their community" to continue in the program. If you don't hear anything at all from your accepted GSoC contributor during community bonding, or the GSoC contributor explicitly drops out, tell Google.
diff --git a/pages/mentor/10-mind_the_gap.md b/pages/mentor/10-mind_the_gap.md
deleted file mode 100644
index ac7b59fd..00000000
--- a/pages/mentor/10-mind_the_gap.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Mind the Gap
-section: Mentoring
-order: 10
-permalink: mentor/mind-the-gap.html
-sidebar: mentor_sidebar
----
-
-The community bonding period is the 3-4 weeks between GSoC student acceptance and the start of coding date. Here are some of the goals of this period:
-
-*   Prepare students to immediately start writing code at the official start of coding.
-*   Get students engaged socially in the project.
-*   Provide time for students to learn about the development practices of the organization.
-*   Ensure that students have a development environment set up. This includes getting set up with the project version control system and reading up on necessary documentation.
-*   Further refine the strategic plan for project completion. Be sure to have solid requirements for all phases particularly the end of the first phase so there is no confusion between your expectations and the student's. Other milestones for phase 2 and the final phase can be adjusted by discussing with the student as needed.
-*   Get required forms filled out, such as the tax forms required by Google, any contributor license agreements, and any paperwork that your project requires.
-
-This period was added in 2007 to help students integrate with their development community and so encourage them to become lifetime contributors. New contributors to a project outside of GSoC often lurk in a project's IRC channel and/or mailing lists for weeks or months before submitting their first patch. The community bonding period is an attempt to improve that experience.
-
-Successful completion of your student's GSoC project depends a lot on the bonding period. Make sure that you and your student make good use of this time and make significant progress on preliminary tasks. The community bonding period is also a good chance for the students to start interacting with each other. Early connections can help the students support each other during coding.
-
-Ideally students are ready to start writing code at the official start of coding, and are already engaged socially. During the community bonding period students are expected to learn about the development processes of their organization, ensure they have a development environment set up, get set up with the project version control system, read up on necessary documentation, and further refine the strategic plan for successful project completion.
-
-Plan weekly activities for your student that only take an hour or two. The community bonding period occurs when students are likely to still be taking classes and have a full load of course work. It's unreasonable to expect that the student will be available full-time to work on GSoC at that point.
-
-**Pro Tip**: Students are meant to be "in good standing with their community" to continue in the program. If you don't hear anything at all from your accepted student during community bonding, or the student explicitly drops out, tell Google.
-
-
diff --git a/pages/mentor/11-setting_expectations.md b/pages/mentor/11-setting_expectations.md
index 7c0f057e..0dc16aad 100644
--- a/pages/mentor/11-setting_expectations.md
+++ b/pages/mentor/11-setting_expectations.md
@@ -6,32 +6,48 @@ permalink: mentor/setting-expectations.html
 sidebar: mentor_sidebar
 ---
 
-Successful mentors set expectations at the start of their projects. This includes communication frequency, project goals, availability and ways of delivering feedback. While the mentor should take the lead in expectation setting, the process of creating and documenting the expectations must be collaborative. Students and mentors need to agree on what is expected, or success becomes quite difficult.
-
+Successful mentors set expectations at the start of their projects. This includes communication frequency, project goals, availability and ways of delivering feedback. While the mentor should take the lead in expectation setting, the process of creating and documenting the expectations must be collaborative. GSoC contributors and mentors need to agree on what is expected, or success becomes quite difficult.
 
 ## Defining Success
 
-Performance measures make it easier to provide feedback, to help your student get back on track if she veers off-course. Clearly stated measures also help you make a fair determination that a student needs to removed from the program.
-
-**Get student input:** Make sure your student has input into the types of performance measures used to determine success or failure. It is very important that your student helps create the performance measures to determine project success and failures. Your relationship should be a highly collaborative one.
+Performance measures make it easier to provide feedback, to help your GSoC contributor get back on track if they veer off-course. Clearly stated measures also help you make a fair determination that a GSoC contributor needs to be removed from the program.
 
-**Set achievable goals:** Help your student come up with manageable project goals. Rather than defining the project as one giant chunk, help your student break the project goals down into smaller pieces or "inchstones" that allow a change in direction if necessary. It is sad to work the entire summer on one giant deliverable, only find out in the last few weeks that the architecture or design is defective.
+**Get GSoC contributor input:** Make sure your GSoC contributor has input into the types of performance measures used to determine success or failure. It is very important that your GSoC contributor helps create the performance measures to determine project success and failures. Your relationship should be a highly collaborative one.
 
-**Anticipate time away:** Make sure to set expectations for known or planned time away from the project, such as course work, vacation trips or holiday time. Talk about how many hours or deliverables per week would be reachable goals and what amount would be a good stretch goal.
+**Set achievable goals:** Help your GSoC contributor come up with manageable project goals. Rather than defining the project as one giant chunk, help your GSoC contributor break the project goals down into smaller pieces or "inchstones" that allow a change in direction if necessary. It is sad to work the entire summer on one giant deliverable, only to find out in the last few weeks that the architecture or design is defective.
 
+**Anticipate time away:** Make sure to set expectations for known or planned time away from the project, such as course work, vacation trips, holiday time, wedding, etc. Talk about how many hours or deliverables per week would be reachable goals and what amount would be a good stretch goal. With the new flexibility in the program allowing for extensions of the coding period it is reasonable to decide with your GSoC contributor that their coding period should be 16 weeks instead of the standard 12 weeks since they have a few weeks they know they will be very busy with other life happenings. Or the two of you can decide together to spread the expected hours per week over a longer period just as that is better for the GSoC contributor. For example, if the GSoC contributor is working on a 350 hour project then you both could decide to spread it over 18 weeks so the GSoC contributor would be coding ~20 hours a week, versus ~30 hours a week over a 12 week coding period.
 
 ## Managing Output
 
-Decide in advance what happens when project goals aren't met. Remember to be flexible if your student has made good progress or has obviously worked hard but needs to re-scope the project at mid-term. Good project management is hard. Your performance measures will help you manage project modifications.
+Decide in advance what happens when project goals aren't met. Remember to be flexible if your GSoC contributor has made good progress or has obviously worked hard but needs to re-scope the project at mid-term. Good project management is hard. Your performance measures will help you manage project modifications.
+
+**Plan for Slippage**: Have a plan to deal with scope-creep and timeline slippage. What if something happens that prevents your GSoC contributor from working successfully for an extended period of time? At which point do you need to terminate the project? Have a plan in place for these scenarios.
+
+**Gather Feedback**: Your GSoC contributor's wishes and desires for a successful project are as important as the project goals. Make sure that you solicit and incorporate their feedback when coming up with initial goals, performance measures and communication methods.
+
+Overall, communicate and be reasonable when it comes to your GSoC contributors. Be ready to revise project plans if an unexpected requirement or bug occurs.
+
+**Pro Tip**: Ask about the weather and local stability of public services. Is your GSoC contributor using the cafe down the street for Internet access? Are there seasonal weather conditions that may lead to flooding and the subsequent inability to turn-on one's computer? Work on a plan to address these types of environmental issues that can affect both communication and output.
+
+**Don't Be That Person**: No one likes dictators.  Work with your GSoC contributor on the development of expectations, rather then barking out orders.
+
+## Project Size vs Project Length
+
+In 2022, Google introduced 2 new features to allow more flexibility to the program: 1) multiple project sizes and 2) multiple possible project lengths. These are very different features and aren't correlated to one another, despite what most folks think. :) A medium project (175 hours) could be a 22 week project if that is what the Mentor,  GSoC Contributor, and Org Admin agree to. And a large project (350 hours) could be 10 weeks if agreed upon by all.
+
+**Project Size**: Projects can be designed to be ~90 hour projects, ~175 hour projects or ~350 hour projects. When a potential GSoC Contributor submits their proposal to an organization they indicate the size of the project: small (~90 hours), medium (~175 hours) or large (~350 hours). A mentor or Org Admin can not increase the size of the project but they can contact Google Program Admins to downsize a project from large to medium or medium to small as needed - preferably during the community bonding period before coding begins.
 
-**Plan for Slippage**: Have a plan to deal with scope-creep and timeline slippage. What if something happens that prevents your student from working successfully for an extended period of time? At which point do you need to terminate the project? Have a plan in place for these scenarios.
+**Project Length**:  The Coding period of a GSoC Contributor project can be 10-22 weeks. The standard coding project length is 12 weeks regardless of the project size (small, medium or large).
 
-**Gather Feedback**: Your student's wishes and desires for a successful project are as important as the project goals. Make sure that you solicit and incorporate her feedback when coming up with initial goals, performance measures and communication methods.
+All projects by default are 12 week projects. If a Mentor and GSoC Contributor agree that they want a project to be a different length, for example, 16 weeks, then they ask the Org Admin to adjust the Project Timeline on the GSoC webapp. Adjustments to a project's timeline (and thus length) must be done before an evaluation phase begins. An Org Admin can not change a midterm evaluation deadline once the midterm evaluation period has begun (same with final submission period).
 
-Overall, communicate and be reasonable when it comes to your students. Be ready to revise project plans if an unexpected requirement or bug occurs.
+A small project should not be longer than 12 weeks.
 
-**Pro Tip**: Ask about the weather and local stability of public services. Is your student using the cafe down the street for Internet access? Are there seasonal weather conditions that may lead to flooding and the subsequent inability to turn-on one's computer? Work on a plan to address these types of environmental issues that can affect both communication and output.
+Sometimes a project is extended to the 18 or 20 weeks because the GSoC Contributor is unable to really get their project going until a few weeks or so later into the coding period due to other commitments (exams, graduation, wedding, etc.). This is why we have designed the program to allow a medium or large project to be anywhere in the 10-22 week period.
 
-**Don't Be That Person**: No one likes dictators.  Work with your student on the development of expectations, rather then barking out orders.
+The GSoC webapp allows Org Admins to adjust the project length by selecting from a dropdown menu on the contributor's project page in the timelines section where they can select 10,12,14,16,18,20 or 22 weeks for the medium and large projects. Small projects can be 8,10 or 12 weeks. When the Org Admin selects the project length it will update all of the dates for the rest of the program based on that timeline. Org Admins can not adjust dates to anything other than these options.
 
+Reminder emails are sent to all Assigned Mentors on a project and to the GSoC Contributors based on the Project's length. Each Mentor and GSoC Contributor will receive a reminder email 10 days before their evaluation period begins and another reminder the day their evaluation period opens. If a Mentor or GSoC Contributor has not submitted their evaluation (or final submission) 24 hours before their deadline they will receive a final reminder email (the Org Admin will also receive the email that the Mentor has not completed the evaluation yet).
 
+Important Note: Org Admins have the final say in whether they want to allow various project lengths or if they want all of their projects to be the standard 12 week projects. While the flexibilty is great for many, it can be more cumbersome for the Org Admins as they have to keep track of the various dates for projects (available from their Org Admin view of all Projects for their org).
diff --git a/pages/mentor/12-workflow.md b/pages/mentor/12-workflow.md
index 89f1cf56..ccda3d3a 100644
--- a/pages/mentor/12-workflow.md
+++ b/pages/mentor/12-workflow.md
@@ -6,29 +6,27 @@ permalink: mentor/workflow.html
 sidebar: mentor_sidebar
 ---
 
-Make sure that your student is familiar with the workflow of your community as early as possible. Learning the toolchain a project uses, such as libraries, version control systems and bugtrackers, is high priority. Workflow also encompasses code review, talking with other developers about which algorithm is best for the problem at hand and other meta-questions about how to best get from specification to implemented solution.
+Make sure that your GSoC contributor is familiar with the workflow of your community as early as possible. Learning the toolchain a project uses, such as libraries, version control systems and bugtrackers, is high priority. Workflow also encompasses code review, talking with other developers about which algorithm is best for the problem at hand and other meta-questions about how to best get from specification to implemented solution.
 
 The best kind of workflows for the GSoC projects are iterative. That means that small, quantifiable goals are defined and then acted upon. For instance, an example of an iterative workflow is:
 
-*   Write a test that demonstrates what feature will be added.
-*   Run the test to verify that it fails in the way you think it should.
-*   If it fails in an unexpected way, your test may be wrong. This is a great time to ask your mentor for guidance.
-*   If it passes, you are done! You just added test coverage to an already existing feature, and that is great!
-*   Add the feature (also known as "a simple matter of programming").
-*   Run the test to verify that it passes.
-*   Write documentation about your feature.
-*   Rejoice appropriately.
+* Write a test that demonstrates what feature will be added.
+* Run the test to verify that it fails in the way you think it should.
+* If it fails in an unexpected way, your test may be wrong. This is a great time to ask your mentor for guidance.
+* If it passes, you are done! You just added test coverage to an already existing feature, and that is great!
+* Add the feature (also known as "a simple matter of programming").
+* Run the test to verify that it passes.
+* Write documentation about your feature.
+* Rejoice appropriately.
 
 This iterative workflow is known as Test Driven Development (TDD). This workflow gets applied to each feature that will be implemented, so a TDD workflow will consist of many cycles of the above steps, each for a different feature. The polar opposite of this workflow looks something like this:
 
-*   Write code the first 1/3rd of the summer
-*   Write tests the next 1/3rd of the summer
-*   Write documentation for the last 1/3rd of the summer
+* Write code the first 1/3rd of the summer
+* Write tests the next 1/3rd of the summer
+* Write documentation for the last 1/3rd of the summer
 
-This is almost always doomed to failure, since people are always optimistic about time estimates for completing something. Sometimes you must debug a weird issue. You can't predict how long it might take to resolve the issue. What usually happens in this workflow is that the code gets written, but takes longer, half the tests get written and no documentation is written because the students have run out of time.
+This is almost always doomed to failure, since people are always optimistic about time estimates for completing something. Sometimes you must debug a weird issue. You can't predict how long it might take to resolve the issue. What usually happens in this workflow is that the code gets written, but takes longer, half the tests get written and no documentation is written because the GSoC contributors have run out of time.
 
-Take an approach which produces usable code even if parts of your plan fail, or are never attempted. Be humble and flexible about your development model. The student may teach you something!
+Take an approach which produces usable code even if parts of your plan fail, or are never attempted. Be humble and flexible about your development model. The GSoC contributor may teach you something!
 
 **Pro Tip**: Progressive milestones may allow code to be merged progressively.
-
-
diff --git a/pages/mentor/13-managing_the_plan.md b/pages/mentor/13-managing_the_plan.md
index aca65493..a813df61 100644
--- a/pages/mentor/13-managing_the_plan.md
+++ b/pages/mentor/13-managing_the_plan.md
@@ -6,53 +6,48 @@ permalink: mentor/managing-the-plan.html
 sidebar: mentor_sidebar
 ---
 
-The student and organization application process to GSoC helps all participants think about how to run the Google Summer of Code at a community level. One important tool is the creation of a strategic plan. The phrase "project plan" frequently elicits a Pavlovian response of groans, shrieks and malaise in techies. An even more severe reaction has been observed in open source communities.  So let's talk about a "strategic plan" instead, and how it can help your student be successful.
-
+The GSoC contributor and organization application process to GSoC helps all participants think about how to run the Google Summer of Code at a community level. One important tool is the creation of a strategic plan. The phrase "project plan" frequently elicits a Pavlovian response of groans, shrieks and malaise in techies. An even more severe reaction has been observed in open source communities.  So let's talk about a "strategic plan" instead, and how it can help your GSoC contributor be successful.
 
 ## Creating a Strategic Plan
 
-The GSoC application process assists in developing a good preliminary outline of a strategic plan for the student's accepted project. To increase the probability of program success you should spend time with your student, and your development community, refining the plan developed in the application period. This can be done during the community bonding period.
+The GSoC application process assists in developing a good preliminary outline of a strategic plan for the GSoC contributor's accepted project. To increase the probability of program success you should spend time with your GSoC contributor, and your development community, refining the plan developed in the application period. This can be done during the community bonding period.
 
-Please note that even though you and your student can decide to change the project from what was originally proposed, **both** of you need to agree on the change. It is important to make sure that the student has the appropriate background knowledge for the new changes. Students will be able to edit their project title and abstract until the coding officially begins.
+Please note that even though you and your GSoC contributor can decide to change the project from what was originally proposed, **both** of you need to agree on the change. It is important to make sure that the GSoC contributor has the appropriate background knowledge for the new changes. GSoC contributors will be able to edit their project title and abstract until the coding officially begins.
 
 A good strategic plan includes:
 
-**A high-level design document**: Think about the architecture and design of the new feature or enhancements that you are making to your community's project. Take some time to teach your student to think about usability by writing a few quick use cases and scenarios, and consider the introduction of any new dependencies.
-
-**Progressive milestones that build on the previous work**: At the completion of each milestone you and your student should take the opportunity to celebrate the accomplishment and reflect upon it. Using progressive milestones also gives you a good measure of how far you have come, which can be very useful during periods of frustration. Additionally, if you don't reach all of the final goals of the project, you will have tangible achievements to point to when reviewing progress with your student. Reinforcement of a student's tangible accomplishments encourages them to stick around and helps to create life-time contributors.
+**A high-level design document**: Think about the architecture and design of the new feature or enhancements that you are making to your community's project. Take some time to teach your GSoC contributor to think about usability by writing a few quick use cases and scenarios, and consider the introduction of any new dependencies.
 
-**Target completion dates for each milestone**: In reality, completion dates are going to move. Nonetheless, a target date gives you a time frame for closure and helps control "scope creep". Coach your students in how to recognize that a milestone is going to be missed, and to notify the project participants before the dates passes.
+**Progressive milestones that build on the previous work**: At the completion of each milestone you and your GSoC contributor should take the opportunity to celebrate the accomplishment and reflect upon it. Using progressive milestones also gives you a good measure of how far you have come, which can be very useful during periods of frustration. Additionally, if you don't reach all of the final goals of the project, you will have tangible achievements to point to when reviewing progress with your GSoC contributor. Reinforcement of a GSoC contributor's tangible accomplishments encourages them to stick around and helps to create life-time contributors.
 
-**Tasks associated with each milestone**: Because your milestones are most likely going to be chunks of code, each milestone needs to include both testing and documentation around that particular "chunk." This approach helps guarantee that you and your student don't end up with a pile of code that hasn't been tested or documented at the end of GSoC.
+**Target completion dates for each milestone**: In reality, completion dates are going to move. Nonetheless, a target date gives you a time frame for closure and helps control "scope creep". Coach your GSoC contributors in how to recognize that a milestone is going to be missed, and to notify the project participants before the dates passes.
 
+**Tasks associated with each milestone**: Because your milestones are most likely going to be chunks of code, each milestone needs to include both testing and documentation around that particular "chunk." This approach helps guarantee that you and your GSoC contributor don't end up with a pile of code that hasn't been tested or documented at the end of GSoC.
 
 ## Following the Plan
 
 After you create a strategic plan, you actually need to follow it. Some ways you can use your strategic plan to stay on track are:
 
-**Collect regular status reports**: Status reports are an important communication tool. They are also important in making sure that time-line slippages and scope creep are addressed in a proactive manner. You do not want to find out two weeks after a milestone due date that your student has slipped the date because they have been unable to solve a simple problem.
+**Collect regular status reports**: Status reports are an important communication tool. They are also important in making sure that time-line slippages and scope creep are addressed in a proactive manner. You do not want to find out two weeks after a milestone due date that your GSoC contributor has slipped the date because they have been unable to solve a simple problem.
 
 **Check off associated milestone tasks**: Find a way to keep track of tasks, and then indicate when they are completed. This can be as simple as keeping an informal to-do list in that is referenced in weekly status reports. You can also use the project management software that the rest of your organization uses. Do what works best within your community, but make sure you do something.
 
-**Set an expectation of prior notification of missed deadlines**: Your student is going to miss project deadlines. Make sure that they understand that it is important to notify you of the missed deadline well in advance. Understanding how long something is going to take to complete is a valuable skill, but it is one that is learned through ongoing evaluation.
-
-**If your student misses a deadline, make sure you discuss why**: Helping your student understand where they become bogged down or stuck helps with future strategic plan development. Remember that you are cultivating a long-time contributor.
+**Set an expectation of prior notification of missed deadlines**: Your GSoC contributor is going to miss project deadlines. Make sure that they understand that it is important to notify you of the missed deadline well in advance. Understanding how long something is going to take to complete is a valuable skill, but it is one that is learned through ongoing evaluation.
 
-**Be a good example**: If you, the mentor, need to miss a deadline, make sure you communicate this to your student well in advance.
+**If your GSoC contributor misses a deadline, make sure you discuss why**: Helping your GSoC contributor understand where they become bogged down or stuck helps with future strategic plan development. Remember that you are cultivating a long-time contributor.
 
+**Be a good example**: If you, the mentor, need to miss a deadline, make sure you communicate this to your GSoC contributor well in advance.
 
 ## Delivering Feedback
 
-Throughout the project you should be delivering effective feedback to your student about their code, communication, and documentation.
+Throughout the project you should be delivering effective feedback to your GSoC contributor about their code, communication, and documentation.
 
-**Deliver feedback early**: Don't wait until several issues have come up, or until your student has impressed you multiple times with their efficiency. Let them know right away what you think about their work.
+**Deliver feedback early**: Don't wait until several issues have come up, or until your GSoC contributor has impressed you multiple times with their efficiency. Let them know right away what you think about their work.
 
-**Make a point to give positive feedback**: The open source community parcels out compliments all too frugally. When a student completes a task on time, and especially when they exceed your expectations, let them know! Early praise is a far better motivator than late criticism.
+**Make a point to give positive feedback**: The open source community parcels out compliments all too frugally. When a GSoC contributor completes a task on time, and especially when they exceed your expectations, let them know! Early praise is a far better motivator than late criticism.
 
-**Don't avoid critique, but don't be a jerk**: Try to put yourself in your student's shoes, and consider how you might want to hear constructive criticism. Phrase suggestions positively.  If criticism is personal in nature (i.e. tone of an email, timeliness or other non-code issues), deliver it in private rather than in a public forum. When in doubt, ask for advice from more experienced mentors or from your organization's administrator.
+**Don't avoid critique, but don't be a jerk**: Try to put yourself in your GSoC contributor's shoes, and consider how you might want to hear constructive criticism. Phrase suggestions positively.  If criticism is personal in nature (i.e. tone of an email, timeliness or other non-code issues), deliver it in private rather than in a public forum. When in doubt, ask for advice from more experienced mentors or from your organization's administrator.
 
 **Pro Tip**: Don't let the development of your design document become your GSoC project. It's useful to set a date for completion of your strategic plan and add a "Start of Coding" milestone.
 
-**Don't Be That Person**: Don't be overly-critical of date slippage. It happens.  Fanatical adherence to dates does not lead to successful project completion, nor does it make your student feel excited to contribute to your community long-term.
-
-
+**Don't Be That Person**: Don't be overly-critical of date slippage. It happens. Fanatical adherence to dates does not lead to successful project completion, nor does it make your GSoC contributor feel excited to contribute to your community long-term.
diff --git a/pages/mentor/14-evaluations.md b/pages/mentor/14-evaluations.md
index 28870059..00cef44e 100644
--- a/pages/mentor/14-evaluations.md
+++ b/pages/mentor/14-evaluations.md
@@ -6,36 +6,37 @@ permalink: mentor/evaluations.html
 sidebar: mentor_sidebar
 ---
 
-Evaluations are a critical component of the GSoC program. Throughout the program evaluations serve to expose process flaws, assess performance, and precipitate pass/fail decisions. Taking time to evaluate the progress and workflow of the project provides an opportunity to correct course and address underlying issues. Most importantly, it provides a structure in which to give valuable criticism and praise to the students. After all, they are supposed to be actively learning (not just working) and effective learning requires evaluation.
+Evaluations are a critical component of the GSoC program. Throughout the program evaluations serve to expose process flaws, assess performance, and precipitate pass/fail decisions. Taking time to evaluate the progress and workflow of the project provides an opportunity to correct course and address underlying issues. Most importantly, it provides a structure in which to give valuable criticism and praise to the GSoC contributors. After all, they are supposed to be actively learning (not just working) and effective learning requires evaluation.
 
-Unlike code critique, which happens openly on mailing lists or other public forums, performance evaluations are personal in nature. Delivering the mentor-student evaluations should be done privately. And more generally, remember the maxim: criticize in private, praise in public.
+Unlike code critique, which happens openly on mailing lists or other public forums, performance evaluations are personal in nature. Delivering the mentor-GSoC contributor evaluations should be done privately. And more generally, remember the maxim: criticize in private, praise in public.
 
-There are four types of evaluations:
+There are two types of evaluations:
 
-**Student evaluations**: Each student fills out three evaluations (after 4 weeks of coding, 8 weeks of coding, and at the end of the 12 week program) pertaining to their experience and their interaction with mentors.
+**GSoC contributor evaluations**: Each GSoC contributor fills out two evaluations: at the halfway point of coding and at the end of the program, pertaining to their experience and their interaction with mentors.
 
-**Mentor evaluations**: Mentor fills out three evaluations after 4 weeks of coding, 8 weeks of coding, and at the end of the 12 week program) covering their participation and their student's performance. If there are multiple mentors, only one mentor will complete the evaluation (decide amongst yourselves who that will be beforehand).
+**Mentor evaluations**: Mentor fills out two evaluations: at the halfway point of coding and at the end of the coding period after the GSoC contributor has submitted their final work product. Both evaluations cover their participation and their GSoC contributor's performance. If there are multiple mentors, only one mentor will complete the evaluation (decide amongst yourselves who that will be beforehand).
 
-These are provided online by Google at specified times with deadlines. The deadlines are important for organizing the payments to students based on the pass/fail decisions by their mentors, so you must ensure that you complete your evaluations on time. Remember, if a student fails any evaluation, they will no longer be part of the program and will not receive any more payments from Google.
+These are provided online by Google at specified times with deadlines. The deadlines are important for organizing the payments to GSoC contributors based on the pass/fail decisions by their mentors, so you must ensure that you complete your evaluations on time. Remember, if a GSoC contributor fails any evaluation, they will no longer be part of the program and will not receive any more payments from Google.
 
+We have added more flexibility into the scheduling for GSoC contributor projects - the coding period can be the standard 12 weeks or with GSoC contributor, mentor and org admin agreement it can be extended to a maximum of 22 weeks. Mentors and GSoC contributors should discuss early on when GSoC contributors may need to step away for a bit for a planned break (exams, vacations, etc.). Ideally these will be discussed and agreed upon during the community bonding period to make sure they are on the same page.
 
-## They Won't Know Unless You Tell Them
-
-It is important to note that other than the pass/fail status, students do not have direct access to the evaluations of their performance. Mentors are welcome to make a copy of their evaluation and share it with students directly. Students are welcome to do the same, but it is not required for either the mentor or student to share their evaluations with the other. Make sure to thoroughly check the topics covered by the evaluations regardless of your choice to share them with one another.
+GSoC contributors will be expected to complete 40-50% of their project by the first evaluation which is the halfway point of the program (at the end of 6 weeks for a standard timed project) if they want to pass their evaluation. Also if a GSoC contributor completes their project 8 weeks into the 12 week program, that's great, but they still have to log back into their GSoC dashboard during the final evaluation period to submit their final evaluation and work product URL in order to pass the program.
 
-Mentors may not have access to student evaluations. Org admins have access to all evaluations submitted by their org's mentors and students.  Mentors have access only to their own evaluations, not to the evaluations submitted by their student.  Thus, if you want to give feedback to your student (and you should!) you need to send this feedback directly to them. There is a field on the evaluation form where you can make a direct comment that will be sent to the student's email.  It is important for mentors and org admins to coordinate in assessing the student and mentor evaluations and taking appropriate follow-up action.
+## They Won't Know Unless You Tell Them
 
-Evaluations should result in a direct review of the student's progress and should be conducted using a real-time communication medium. This can be by phone, your favorite voice-over-IP service, or in person. The discussion should be frank and in the context of periodic review so that the student is prepared for criticism and to work with you to revise workflows, timelines and habits. Take time to explain the value of learning how to take criticism and praise in a professional setting.
+It is important to note that other than the pass/fail status, GSoC contributors do not have direct access to the evaluations of their performance. Mentors are welcome to make a copy of their evaluation and share it with GSoC contributors directly. GSoC contributors are welcome to do the same, but it is not required for either the mentor or GSoC contributor to share their evaluations with the other. Make sure to thoroughly check the topics covered by the evaluations regardless of your choice to share them with one another.
 
-When delivering reviews of student performance, be specific about both positive and negative aspects of a student's performance. Make the suggestions for change or improvement relevant to what your student is currently working on, and provide specific examples. As you prepare for your student's review, you might write it out as though you were sending an email; this will help you to frame your thoughts and to ensure that you are providing a balanced perspective. Make the student aware of the review schedule well in advance. If you provide a written copy of the review, schedule time for discussion immediately after the student reads it.
+Org admins have access to all evaluations submitted by their org's mentors.  Mentors have access only to their own evaluations, not to the evaluations submitted by their GSoC contributor. There is a field on the evaluation form where you can make a direct comment that will be sent to the GSoC contributor's email.  It is important for mentors and org admins to coordinate in assessing the GSoC contributor and mentor evaluations and taking appropriate follow-up action. There are a few questions on the GSoC contributor evaluations that can be seen only by org admins (ratings of their mentor, etc.). These fields are clearly marked on the GSoC contributor dashboard so they know who can or can not see them.
 
+Evaluations should result in a direct review of the GSoC contributor's progress and should be conducted using a real-time communication medium. This can be by phone, your favorite voice-over-IP service, or in person. The discussion should be frank and in the context of periodic review so that the student is prepared for criticism and to work with you to revise workflows, timelines and habits. Take time to explain the value of learning how to take criticism and praise in a professional setting.
 
-## When in Doubt, Fail the Student Early
+When delivering reviews of GSoC contributor performance, be specific about both positive and negative aspects of a GSoC contributor's performance. Make the suggestions for change or improvement relevant to what your GSoC contributor is currently working on, and provide specific examples. As you prepare for your GSoC contributor's review, you might write it out as though you were sending an email; this will help you to frame your thoughts and to ensure that you are providing a balanced perspective. Make the GSoC contributor aware of the review schedule well in advance. If you provide a written copy of the review, schedule time for discussion immediately after the GSoC contributor reads it.
 
-This is harsh-sounding advice. However, GSoC stats show that more than 80% of the students who are reported as marginal at or before the first evaluation eventually fail GSoC.  Whatever problems your student is currently having, they are likely to be worse than you currently appreciate, and to get worse rather than better over time.  You are not doing your student, much less yourself, a service by prolonging the agony.  Most GSoC students and their mentors have a great time and get a lot done.  If you are having the other kind of experience, cut your losses and try again next year. Remember there are hundreds of students diligently working on their projects and if you give a student a pass simply because you feel guilty failing them (even though they are not meeting deadlines or communicating) then you are doing a disservice to all of the other hardworking students.
+## When in Doubt, Fail the GSoC contributor Early
 
-Note that GSoC gives mentoring orgs quite a bit of flexibility and cuts them a lot of slack. Students need to understand that they are being evaluated from before they are accepted to the end of the program, and that you take the GSoC experience seriously and expect them to do likewise.
+This is harsh-sounding advice. However, GSoC stats show that more than 80% of the GSoC contributors who are reported as marginal at or before the first evaluation eventually fail or withdraw from GSoC.  Whatever problems your GSoC contributor is currently having, they are likely to be worse than you currently appreciate, and to get worse rather than better over time.  You are not doing your GSoC contributor, much less yourself, a service by prolonging the agony.  Most GSoC contributors and their mentors have a great time and get a lot done.  If you are having the other kind of experience, cut your losses and try again next year. Remember there are hundreds of GSoC contributors diligently working on their projects and if you give a GSoC contributor a pass simply because you feel guilty failing them (even though they are not meeting deadlines or communicating) then you are doing a disservice to all of the other hardworking GSoC contributors.
 
+Note that GSoC gives mentoring orgs quite a bit of flexibility and cuts them a lot of slack. GSoC contributors need to understand that they are being evaluated from before they are accepted to the end of the program, and that you take the GSoC experience seriously and expect them to do likewise.
 
 ## It's Not *Impossible* to Turn Things Around
 
@@ -49,13 +50,10 @@ Additionally, a second mentor was brought in, so that a mentor would always be a
 
 By the final evaluation, the student was almost back on his original project plan, and had completed all the required goals.
 
-It is possible to rescue a failing student, but you need to really consider the issues, and come up with a plan to address them which everyone involved buys into. You also need to be prepared for the project to fail, and be okay with the extra energy you have invested not resulting in the outcome you wanted.
-
+It is possible to rescue a failing GSoC contributor, but you need to really consider the issues, and come up with a plan to address them which everyone involved buys into. You also need to be prepared for the project to fail, and be okay with the extra energy you have invested not resulting in the outcome you wanted.
 
 ## Mentor, Heal Thyself
 
-This is also an important time for self-evaluation. Are you managing your time adequately? Do you know where the project is at and where it is going? Are you enforcing the deadlines you set? Are you integrating your student into your community?
-
-Take the evaluation period as an opportunity to get feedback from students. Is there any way that you could have helped the student more? How does the student think you might be more effective as a mentor? Ask your student directly for feedback.
-
+This is also an important time for self-evaluation. Are you managing your time adequately? Do you know where the project is at and where it is going? Are you enforcing the deadlines you set? Are you integrating your GSoC contributor into your community?
 
+Take the evaluation period as an opportunity to get feedback from GSoC contributors. Is there any way that you could have helped the GSoC contributor more? How does the GSoC contributor think you might be more effective as a mentor? Ask your GSoC contributor directly for feedback.
diff --git a/pages/mentor/15-special_circumstances.md b/pages/mentor/15-special_circumstances.md
index e8f7b981..8777c298 100644
--- a/pages/mentor/15-special_circumstances.md
+++ b/pages/mentor/15-special_circumstances.md
@@ -8,27 +8,28 @@ sidebar: mentor_sidebar
 
 GSoC participants, being human, will sometimes get sick or have something come
 up in their life (i.e. death in the family) during GSoC and this can affect
-their performance. A student's (or mentor's) health is more important than a
+their performance. A GSoC contributor's (or mentor's) health is more important than a
 GSoC project.
 
 Do's:
 
-+   Encourage the participant to focus on their health concerns as their priority.
-+   Provide reasonable accommodations and understanding.
++ Encourage the participant to focus on their health concerns as their priority.
++ Provide reasonable accommodations and understanding.
++ Remember that Org Admins can extend a project length so if this is a situation that the person can likely recover from in a few weeks then you can extend the project by 2, 4, 6 or up to 10 additional weeks (maximum project length of 22 weeks for medium and large size projects).
 
 Dont's:
 
-+   Pry into the details of the situation. It's none of your business.
-+   Ask for a doctor's note or proof.
-+   Make promises about extensions outside the normal GSoC dates.
-+   Require students to withdraw. This is their choice.
++ Pry into the details of the situation. It's none of your business.
++ Ask for a doctor's note or proof.
++ Make promises about extensions outside the normal GSoC dates. With the extensions now available, the max of 22 weeks should be more than enough if you and your org choose to allow the GSoC contributor to extend their final deadline.
++ Require GSoC contributors to withdraw. This is their choice.
 
-When evaluating students, be cognizant of the amount of time they have put in.
-A student who has produced good work for most of an evaluation period may be
-passed. A student who has only spent a few days working shouldn't be passed. If
-a student needs to take a week off, that shouldn't be an automatic fail.
-Evaluate the big picture. Students should only be passed for work they've
-already done, not work they might do. Failing a student who has a special
+When evaluating GSoC contributors, be cognizant of the amount of time they have put in.
+A GSoC contributor who has produced good work for most of an evaluation period may be
+passed. A GSoC contributor who has only spent a few days working shouldn't be passed. If
+a GSoC contributor needs to take a week off, that shouldn't be an automatic fail.
+Evaluate the big picture. GSoC contributors should only be passed for work they've
+already done, not work they might do. Failing a GSoC contributor who has a special
 circumstance isn't easy, but might be the right thing to do.
 
-Note: Students must still complete their evaluation in order to be passed.
+Note: GSoC contributors must still complete their final evaluation in order to be passed.
diff --git a/pages/mentor/16-upstream_integration.md b/pages/mentor/16-upstream_integration.md
index ee27a3b3..d690e053 100644
--- a/pages/mentor/16-upstream_integration.md
+++ b/pages/mentor/16-upstream_integration.md
@@ -8,35 +8,31 @@ sidebar: mentor_sidebar
 
 Every project wants to get useful code. And once you get that code, you'd love to be able to commit it to your project and make use of it! The following are some helpful hints on making that process easier on both the students and the committers to your project.
 
-**Note**: We use the term 'committer' throughout this section to mean the person or people responsible for adding or merging code to your organizations authoritative source code repository. Terminology and source control methods vary so widely, that it was difficult to choose a single term. Committer seemed to cover the widest variety of situations.
-
+**Note**: We use the term 'committer' throughout this section to mean the person or people responsible for adding or merging code to your organization's authoritative source code repository. Terminology and source control methods vary so widely, that it was difficult to choose a single term. Committer seemed to cover the widest variety of situations.
 
 ## Recruit Committers Early
 
-Typically, one or more committers to your project will be involved in GSoC. For very large projects, it can be helpful to alert all committers to upcoming student submissions. You can ask for them to be a second reviewer on patches from students, or simply keep them informed of your student's work schedule. This helps them know approximately when to expect code submissions.
-
+Typically, one or more committers to your project will be involved in GSoC. For very large projects, it can be helpful to alert all committers to upcoming GSoC contributor submissions. You can ask for them to be a second reviewer on patches from GSoC contributors, or simply keep them informed of your GSoC contributor's work schedule. This helps them know approximately when to expect code submissions.
 
 ## Get The Code
 
-It's best if you can get the code committed to your project's repository as early as possible. Whether you commit this to your project's equivalent of HEAD, to a development branch or a feature-specific branch, getting student's code into a publicly available and canonical location early is a good thing.
-
-Even if your organization is unwilling to have student code drop directly into a released or releasable version of the org's project, it is a good idea to make sure that it is captured by the organization somehow. This ensures that you and your organization has a backup copy of the student's work. Getting the student's code into an unstable version or feature branch at the start of GSoC ensures that everything of value will be captured, decreases the eventual integration burden, and provides a better mechanism for community review of student code.
+It's best if you can get the code committed to your project's repository as early as possible. Whether you commit this to your project's equivalent of HEAD, to a development branch or a feature-specific branch, getting a GSoC contributor's code into a publicly available and canonical location early is a good thing.
 
+Even if your organization is unwilling to have GSoC contributor code drop directly into a released or releasable version of the org's project, it is a good idea to make sure that it is captured by the organization somehow. This ensures that you and your organization has a backup copy of the GSoC contributor's work. Getting the GSoC contributor's code into an unstable version or feature branch at the start of GSoC ensures that everything of value will be captured, decreases the eventual integration burden, and provides a better mechanism for community review of GSoC contributor code.
 
 ## Dividing Up Patches
 
-Many organizations take student code submissions in the form of patches.  It is considered best practice to keep patches confined to a single feature at a time. Sometimes this is not possible, but encouraging students to submit their changes as they are working is always better than a massive "patch bomb" at the end of the program.
+Many organizations take GSoC contributor code submissions in the form of patches.  It is considered best practice to keep patches confined to a single feature at a time. Sometimes this is not possible, but encouraging GSoC contributors to submit their changes as they are working is always better than a massive "patch bomb" at the end of the program.
 
-You can help your student by talking with them about how to divide their code into reasonable submissions to the project. This should include setting time-based milestones, grouping certain features and implementation details together and requiring that tests or specifications be written first. Using pseudocode, rapid prototyping and iterative design methodologies can be helpful in structuring your student's work and keeping you in the loop.
-
-Be sure to set aside some time to teach your students how to use your revision control system, and especially its code merge tools, during the bonding period. This is both for their benefit and to save your time. If the student already knows how to test merging their changes before submitting them, it is far more likely that less time will be spent fixing patches which don't apply.
+You can help your GSoC contributor by talking with them about how to divide their code into reasonable submissions to the project. This should include setting time-based milestones, grouping certain features and implementation details together and requiring that tests or specifications be written first. Using pseudocode, rapid prototyping and iterative design methodologies can be helpful in structuring your GSoC contributor's work and keeping you in the loop.
 
+Be sure to set aside some time to teach your GSoC contributors how to use your revision control system, and especially its code merge tools, during the bonding period. This is both for their benefit and to save your time. If the GSoC contributor already knows how to test merging their changes before submitting them, it is far more likely that less time will be spent fixing patches which don't apply.
 
 ## Patch Review
 
-Make review of submitted patches an explicit task. By doing so, you make it easier to hand some or all of the review off to another member of your community. This kind of delegation makes the student more a part of your development community, and reduces the overall work that is required from you.
+Make review of submitted patches an explicit task. By doing so, you make it easier to hand some or all of the review off to another member of your community. This kind of delegation makes the GSoC contributor more a part of your development community, and reduces the overall work that is required from you.
 
-Ultimately, you'll be responsible for understanding and performing a final review of the code for the student's GSoC evaluation. However, there's nothing wrong with bringing other people into the process.
+Ultimately, you'll be responsible for understanding and performing a final review of the code for the GSoC contributor's GSoC evaluation. However, there's nothing wrong with bringing other people into the process.
 
 Some projects have a documented review process. A good example is on the [PostgreSQL Developers Wiki](http://wiki.postgresql.org/wiki/Reviewing_a_Patch), some of which was used as a reference for this section.
 
@@ -48,16 +44,14 @@ A reviewer does not need to guarantee some level of quality, but they do need to
 
 Questions a patch reviewer might ask include:
 
-*   Does it include reasonable tests, necessary documentation, an overview of features, etc?
-*   Does the patch actually implement what the author intends and work as advertised?
-*   Does it follow a relevant specification, RFC or the community-agreed behavior?
-*   Are there corner cases or failure situations the author has failed to consider?
-*   Does the patch slow down simple tests or other features?
-*   Does it follow the project coding guidelines? For an example, see <http://developer.postgresql.org/pgdocs/postgres/source.html>
-*   Will it work on all supported operating system and hardware platforms?
-*   Are the comments sufficient and accurate? Are there any comments at all?
-*   Does it produce compiler warnings?
-*   Can you make it crash?
-*   Is everything done in a way that fits together coherently with other features/modules?
-
-
+* Does it include reasonable tests, necessary documentation, an overview of features, etc?
+* Does the patch actually implement what the author intends and work as advertised?
+* Does it follow a relevant specification, RFC or the community-agreed behavior?
+* Are there corner cases or failure situations the author has failed to consider?
+* Does the patch slow down simple tests or other features?
+* Does it follow the project coding guidelines? For an example, see <http://developer.postgresql.org/pgdocs/postgres/source.html>
+* Will it work on all supported operating system and hardware platforms?
+* Are the comments sufficient and accurate? Are there any comments at all?
+* Does it produce compiler warnings?
+* Can you make it crash?
+* Is everything done in a way that fits together coherently with other features/modules?
diff --git a/pages/mentor/17-building_a_lifetime_contributor.md b/pages/mentor/17-building_a_lifetime_contributor.md
index e5ca8f45..65b87386 100644
--- a/pages/mentor/17-building_a_lifetime_contributor.md
+++ b/pages/mentor/17-building_a_lifetime_contributor.md
@@ -6,26 +6,24 @@ permalink: mentor/building-a-lifetime-contributor.html
 sidebar: mentor_sidebar
 ---
 
-The work of transforming your summer students into lifetime contributors begins on the first day. Actually, it begins even earlier with the preparation of your development community for student participation and inclusion. In as many ways as possible, you should aim to make the students full members of their community by the end of the program. Actively encourage students to attend community meetings and retreats. Highlight their work within your community. Part of being a mentor is being a cheerleader.
+The work of transforming your GSoC contributors into lifetime contributors begins on the first day. Actually, it begins even earlier with the preparation of your development community for GSoC contributor participation and inclusion. In as many ways as possible, you should aim to make the GSoC contributors full members of their community by the end of the program. Actively encourage GSoC contributors to attend community meetings and retreats. Highlight their work within your community. Part of being a mentor is being a cheerleader.
 
-**Say "thank you" often**: People like to be thanked for their contributions--publicly and privately. Creating an environment of appreciation makes students want to keep contributing.
+**Say "thank you" often**: People like to be thanked for their contributions--publicly and privately. Creating an environment of appreciation makes GSoC contributors want to keep contributing.
 
 **Be gentle with criticism**: Remember that you are cultivating a long-time contributor.  Positive, constructive comments are the most useful as well as the most pleasant to receive.
 
-**Don't airbrush your community**: If you want a student to stick around, you might as well make the experience as realistic as possible. Creating a bubble for the student takes a lot of effort. When it inevitably bursts, they will be disillusioned.
+**Don't airbrush your community**: If you want a GSoC contributor to stick around, you might as well make the experience as realistic as possible. Creating a bubble for the GSoC contributor takes a lot of effort. When it inevitably bursts, they will be disillusioned.
 
-**Credit where due**: Open source has something of a "reputation economy". Create a "CREDITS" file in your code repository dedicated to identifying those people who have contributed to your project, and make sure that they are mentioned by name in the release notes.   As these contributions are credited, mention this publicly on a mailing list or in a blog post. Remember to also acknowledge contributions in public: when your student completes important project milestones, announce their successes to your development community.
+**Credit where due**: Open source has something of a "reputation economy". Create a "CREDITS" file in your code repository dedicated to identifying those people who have contributed to your project, and make sure that they are mentioned by name in the release notes. As these contributions are credited, mention this publicly on a mailing list or in a blog post. Remember to also acknowledge contributions in public: when your GSoC contributor completes important project milestones, announce their successes to your development community.
 
-**Solicit talks at conferences**: Recommend that students present their work at open source conferences. If you can, offer to co-present with them and help with designing their talks. If your organization can offer travel support for the student, this is quite helpful.  If you know people who do work that your student is interested in, or that your student would be impressed to be introduced to, take the time to make introductions.
+**Solicit talks at conferences**: Recommend that GSoC contributors present their work at open source conferences. If you can, offer to co-present with them and help with designing their talks. If your organization can offer travel support for the GSoC contributor, this is quite helpful.  If you know people who do work that your GSoC contributor is interested in, or that your student would be impressed to be introduced to, take the time to make introductions.
 
-**Professional development**: If appropriate, offer written professional recommendations to students. Your help in career advice, job searches or referrals can be invaluable for a student.
+**Professional development**: If appropriate, offer written professional recommendations to GSoC contributors. Your help in career advice, job searches or referrals can be invaluable for a GSoC contributor.
 
-**Retreats and hackfests**: If your organization is having a retreat or hosting a hackfest, invite your students along! Find ways of integrating them into your group the same way you would any other contributor.
+**Retreats and hackfests**: If your organization is having a retreat or hosting a hackfest, invite your GSoC contributors along! Find ways of integrating them into your group the same way you would any other contributor.
 
-**Stay in contact**: Open source organizations typically sustain themselves through the personal connections developers have to each other. Many contributors consider each other friends, and communicate non-technical information to each other. Remember though, that this is a student and GSoC is their job, so when in doubt err on the side of communicating professionally--no matter how informal the tone of your overall community.
-
-Communicate early and communicate often! Try sending periodic emails to check in, pass on an interesting link or share a photo. Social networks can be useful for maintaining contact without a lot of overhead. Examples include: Identi.ca, Flickr, and GitHub. Use what works for you, and don't feel pressured to get involved with a social network.  The telephone is also a valuabe resource; studies of open source communications have shown that VOIP technology is used with surprising frequency in open source projects, and it is a very personal and friendly form of communication.
-
-**Don't Be That Person**: Be socially and culturally sensitive. If you and your student don't share the same cultural background, ask respectful questions so you get to know about the similarities and differences a bit more. Also, make sure to maintain appropriate boundaries in your communications. For example, a student calling in the middle of the night to ask for relationship advice is not a pleasant situation for anyone; leave those conversations for their college friends.
+**Stay in contact**: Open source organizations typically sustain themselves through the personal connections developers have to each other. Many contributors consider each other friends, and communicate non-technical information to each other. Remember though, that during GSoC the mentor and GSoC contributor relationship requires the mentor to be a leader, so when in doubt err on the side of communicating professionally--no matter how informal the tone of your overall community.
 
+Communicate early and communicate often! Try sending periodic emails to check in, pass on an interesting link or share a photo. Social networks can be useful for maintaining contact without a lot of overhead. Examples include: Identi.ca, Flickr, and GitHub. Use what works for you, and don't feel pressured to get involved with a social network.  The telephone is also a valuable resource; studies of open source communications have shown that VOIP technology is used with surprising frequency in open source projects, and it is a very personal and friendly form of communication.
 
+**Don't Be That Person**: Be socially and culturally sensitive. If you and your GSoC contributor don't share the same cultural background, ask respectful questions so you get to know about the similarities and differences a bit more. Also, make sure to maintain appropriate boundaries in your communications. For example, a student calling in the middle of the night to ask for relationship advice is not a pleasant situation for anyone; leave those conversations for their friends.
diff --git a/pages/mentor/18-making_your_ideas_page.md b/pages/mentor/18-making_your_ideas_page.md
index 7ce456e5..d2be827d 100644
--- a/pages/mentor/18-making_your_ideas_page.md
+++ b/pages/mentor/18-making_your_ideas_page.md
@@ -6,19 +6,23 @@ permalink: mentor/making-your-ideas-page.html
 sidebar: mentor_sidebar
 ---
 
-It all begins with the "Ideas Page". This is where you compile a list of possible summer projects for your organization. The Ideas Page is a major piece of your organization's application to Google. It also serves as a recruiting and selection tool for students and mentors alike.
+It all begins with the "Ideas Page". This is where you compile a list of possible GSoC projects for your organization. The Ideas Page is a major piece of your organization's application to Google. It also serves as a recruiting and selection tool for GSoC contributors and mentors alike.
 
-Depending on how your organization operates, the source of material for your Ideas Page may come from an existing list of projects maintained by your community year-round, from potential mentors as they are recruited, or from the org admin. Regardless of how it is generated, an Ideas Page should have the following:
+Depending on how your organization operates, the source of material for your Ideas Page may come from an existing list of projects maintained by your community year-round, from potential mentors as they are recruited, or from the org admin. Regardless of how it is generated, an Ideas Page should have the following listed for each Project Idea:
 
-*   Brief descriptions of projects that can be completed in about 12 weeks.
-*   For each project, a list of prerequisites, description of programming skills needed and estimation of difficulty level.
-*   A list of potential mentors.
-*   It must NOT be a link to your bug tracker.
+* Brief description of project (usually 3-5 sentences, can be longer).
+* List whether the project is scoped to be a ~90 hour (small), ~175 hour (medium) or ~350 hour (large) project.
+* List prerequisites, including a description of programming skills needed
+* Include an estimation of difficulty level (easy, intermediate, hard).
+* A list of potential mentors.
+* It must NOT be a link to your bug tracker.
 
-The best pages include links to more detailed descriptions and related materials for each project. They might even include actual use cases!
+If your org only plans to accept 1 or 2 GSoC contributors due to the number of mentors you have lined up (or if your org is a new org to GSoC) that is okay but you should state at the top of your Ideas List that is your intention. Otherwise GSoC Admins will think you haven't put in the time and effort with your ideas when we only see 1 or 2 ideas listed. GSoC Admins will interpret that as your org isn't prepared to be a GSoC org.
 
-*Keep in mind that this page is often the first view of your organization by Google and potential student applicants**.*** A link to your bug tracker does not an Ideas Page make. Put your best foot forward. In addition to a basic list, you might also consider providing links to relevant resources for mentors and students, particular FAQ entries, the timeline, etc. You might include a section on communication, giving specific advice on which mailing lists, channels and emails to use and how to use them. If your organization puts together an application template for students, you should include that on your page as well. Think of your Ideas Page as the GSoC portal to your organization.
+The best pages include links to more detailed descriptions and related materials for each project. They might even include actual use cases!
 
-***Pro Tip:*** Maintain an Ideas Page year-round to continually recruit new contributors and cultivate community involvement.
+While the Ideas page doesn't have to be 'beautiful,' cluttered and ugly won't be attracting many participants to apply to your org either. Make it clean, which could mean more line breaks or some bold, bigger fonts when appropriate. Blocks of text are not welcoming.
 
+*Keep in mind that this page is often the first view of your organization by Google and potential GSoC contributor applicants**.*** A link to your bug tracker does not an Ideas Page make. Put your best foot forward. In addition to a basic list, you might also consider providing links to relevant resources for mentors and GSoC contributors, particular FAQ entries, the timeline, etc. You might include a section on communication, giving specific advice on which mailing lists, channels and emails to use and how to use them. If your organization puts together an application template for GSoC contributors, you should include that on your page as well. Think of your Ideas Page as the GSoC portal to your organization.
 
+***Pro Tip:*** Maintain an Ideas Page year-round to continually recruit new contributors and cultivate community involvement.
diff --git a/pages/mentor/19-selecting_students_and_mentors.md b/pages/mentor/19-selecting_students_and_mentors.md
index 1e1c7ea7..78970963 100644
--- a/pages/mentor/19-selecting_students_and_mentors.md
+++ b/pages/mentor/19-selecting_students_and_mentors.md
@@ -1,73 +1,73 @@
 ---
-title: Selecting Students and Mentors
+title: Selecting Contributors and Mentors
 section: Org Admin
 order: 19
 permalink: mentor/selecting-students-and-mentors.html
 sidebar: mentor_sidebar
 ---
 
-A key activity for org admins is setting up and supervising the process by which student proposals are prioritized and matched with mentors. There are many good ways to do this. There are also a few common ways to proceed that are not so good. In any case, understanding how organizations commonly approach student and mentor selection can help to ensure a better outcome from this critical step.
-
+A key activity for org admins is setting up and supervising the process by which GSoC contributor proposals are prioritized and matched with mentors. There are many good ways to do this. There are also a few common ways to proceed that are not so good. In any case, understanding how organizations commonly approach GSoC contributor and mentor selection can help to ensure a better outcome from this critical step.
 
 ## The Formal Process
 
-Conceptually, the process of selecting students and mentors is simple. In practice, the process of prioritizing proposals and assigning mentors can be difficult and contentious.
+Conceptually, the process of selecting GSoC contributors and mentors is simple. In practice, the process of prioritizing proposals and assigning mentors can be difficult and contentious.
 
-During the student application period, organizations prioritize the student proposals, discard proposals unworthy of consideration and investigate proposals further. At some point, Google tells the organization how many "slots" the organization will be allowed to fund. The organization administrator will select the org's choices on the program site at the close of the student selection period and they will be funded ("slotted") by Google. Mentors must be assigned to all projects that the organization wants considered for slotting, preferably as early in the process as possible.
+During the GSoC contributor application period (and in the weeks leading up to the application period) mentors discuss project ideas with potential GSoC contributors, organizations prioritize the GSoC contributor proposals based on the conversations they have had with the contributors, discard proposals unworthy of consideration and investigate proposals further. The organization administrator will reach out to the mentors and together they will prioritize the proposals and rank them. Then the organization administrator will submit their organization's requested number of project "slots" on their program dashboard.  Committed mentors must be assigned to all projects that the organization wants considered. Additional mentors can be added later but a minimum of one mentor must be assigned to a proposal or it can not be ranked.
 
-Proposal volumes tend to be high, and the nature of the activity can lead to disagreements and bruised egos. Make the process for deciding on projects clear early, and be consistent.
+GSoC contributor slot selections will be based on the rank an organization gives the proposals.
 
+Proposal volumes tend to be high, and the nature of the activity can lead to disagreements and bruised egos. Make the process for deciding on projects clear early, and be consistent.
 
 ## Slot Count
 
-Google asks your organization how many slots you want slighty before slot allocation, after you have had time to review the student proposals that your organization received. The organization administrator is asked to enter both a minimum number of slots requested and a maximum number of slots requested. When deciding on your top proposals you should also be sure there is at least one mentor that has committed to mentor that project.
+Google asks your organization how many slots you want after you have had time to review the GSoC contributor proposals that your organization received.
 
-The actual number of slots Google assigns to each organization depends on the number of organizations and the number of students Google is going to fund that year. Then the slots are distributed amongst the accepted organizations by Google. Every accepted organization is allocated at least one slot. First-year organizations rarely get more than two slots. No organization ever receives more slots than they asked for.
+The actual number of slots Google assigns to each organization depends on the number of organizations and the number of GSoC contributors Google is going to fund that year. Then the slots are distributed amongst the accepted organizations by Google. Every accepted organization is allocated at least one slot. First-year organizations rarely get more than two slots. No organization ever receives more slots than they asked for.
 
-There is no net advantage to getting as many slots as possible. Sure, more students get paid, and the org gets paid a little more. However, accepting less-than-great applications has a huge cost in time and grief. Google's process for choosing organizations includes the pass/fail ratio. Poor ratios may endanger future participation in GSoC. And if you request more slots than you need you are essentially taking those slots away from other organizations who could have used them for some of the excellent student proposals they received.
+There is no net advantage to getting as many slots as possible. Sure, more GSoC contributors might get paid, and the org gets paid a little more in organization stipends. However, accepting less-than-great applications has a huge cost in time and grief. Google's process for choosing organizations includes the pass/fail ratio. Poor ratios may endanger future participation in GSoC. And if you request more slots than you need you are taking those slots away from other organizations who could have used them for some of the excellent GSoC contributor proposals they received.
 
-If you discover that you haven't received the number of slots you were hoping for then choose the best proposals to match the number of slots you have been given. And be sure to do a great job with those students so that in the next year of GSoC Google may be able to give you a couple more slots the next time around.
+When Google assigns an organization its slots, that number will automatically consider the ranking your organization administrator gave the proposals. For example, if an organization requests 7 slots and is given 5, the proposals that were ranked 1,2,3,4 and 5 will automatically become your accepted GSoC contributor projects.
 
 If you ask for a certain number of slots and are given that number but then realize you don't have enough mentors to cover all of the projects you have essentially wasted that slot and taken it out of the hands of another organization that didn't receive the number of slots they requested relative to their excellent proposals. There is no way to trade unused slots with other organizations.
 
+You can not substitute in other proposals after you have ranked your proposals and received the slot allocations.
+
+## GSoC contributors selected by multiple orgs
 
-## Students selected by multiple orgs
+GSoC contributors are allowed to submit up to 3 proposals each year, and they can be to multiple organizations. When organizations have chosen their desired GSoC contributors based on their ranked slot allocations, it is inevitably the case that a few GSoC contributors are sought by more than one organization (usually around 10-20 each year).
 
-Students are allowed to submit up to 3 proposals each year, and they can be to multiple organizations. When organizations have chosen their desired students based on the number of slots they were given, it is inevitably the case that a few students are sought by more than one organization. Starting in 2016, when an organization chooses their student that another organization has already chosen, the second organization's administrators will receive the contact information for the Organization Administrator with the first organization that chose the student. Then if they wish to plead their case for the first organization to release the student so the second organization can have them for a very important project they can. Ultimately it is up to the first organization that chose the student to decide if they want to release that student and let the second organization have that student. If the first organization releases that student they then can choose another student to fill that slot.
+Ranking is taken into account when slots are allocated to projects. The higher your organization ranks a proposal the more likely your organization will receive it, in the case another organization also ranks a proposal from the same contributor. If a tie breaker is necessary, then Google's AI will select which org will receive the proposal.
 
-This process involves interaction with peer open source organizations. It is critically important that you are polite and cordial, and put the needs of the student first.  Whenever possible, student preferences should be honored. Keep in mind that you may have to work with these organizations outside GSoC; generating ill will here is not worth it. Also keep in mind that Google's program admins emphatically do not want to have to deal with hostility and conflict here. Don't endanger your future participation in GSoC just because some other organization wants some student as much as you do.  Be nice and get out of the way.
+**New in 2025, the GSoC applicants will be able to rank their proposals with their #1, #2 and #3 preferences. Only Google Admins will be able to see these preferences and they will be considered but not guaranteed. Google Admins will go through and review any situations where a contributor was selected by multiple orgs. In the case where the GSoC applicant's 2nd or 3rd choice org was granted their proposal, Google Admins will reach out to that org and let them know the applicant preferred another org over their org. The org will get to decide whether to keep the contributor (might happen if they had no other great applicants for the project idea and it's very important to the org) or they can release that contributor (to their preferred org) and notify Google Admins of who they would like to replace that now empty spot.
 
+If you "lose" the project due to another org ranking it higher, Google will contact you to see which project you would like to replace that slot with. The system will automatically select the next ranked proposal (if your org did not receive all the slots you asked for) but the OA will have a day or so to let Google Admins know if they would prefer to adjust that project slot to a different contributor.
 
 ## Acquiring and Assigning Mentors
 
-Building a mentor pool and matching mentors with projects and students is one of the most challenging tasks for the org admin. For many organizations, the mentor will be selected by project when the ideas page is constructed. For others, mentors will be assigned once students have been selected and matched to projects.
+Building a mentor pool and matching mentors with projects and GSoC contributors is one of the most challenging tasks for the org admin. For many organizations, the mentor will be selected by project when the ideas page is constructed. For others, mentors will be assigned once proposals have been received and right before ranking of slot requests begins.
 
-Look critically at mentor volunteers. Wanting the job is not a sufficient qualification. The mentor should be well-known to the community, and known to be someone reasonable and collegial. The best technical person is not necessarily the best mentor; look for teaching and...well..mentoring skills.
+Look critically at mentor volunteers. Wanting the role is not a sufficient qualification. The mentor should be well-known to the community, and known to be someone reasonable and patient. The best technical person is not necessarily the best mentor; look for teaching and...well...mentoring skills.
 
-Do not be afraid to reach out to folks in the organization who have not volunteered. The ideal mentor for a project may not have heard of GSoC, or may not have considered herself a candidate for mentoring.  She may be flattered to be asked.
+Do not be afraid to reach out to folks in the organization who have not volunteered. The ideal mentor for a project may not have heard of GSoC, or may not have considered themself a candidate for mentoring.  They may be flattered to be asked.
 
 Make sure you have enough mentors, including quite a few spares. Folks who would be capable of mentoring a variety of projects are especially welcome. Strongly consider having enough backup or secondary mentors that every project has an alternate of some sort.
 
-If you (or the mentor) are insecure about their qualifications having them join the project as a back-up mentor is a great strategy to encourage future participation.
-
+If you (or the mentor) are insecure about their qualifications having them join the project as a backup mentor is a great strategy to encourage future participation.
 
 ## Cheating and Proposals From Outer Space
 
-Avoid spending time on proposals that were not tailored to your project by using the "ignore" feature for student proposals.
-
-Occasionally a student does not understand the importance of attribution when drawing on material from outside sources. Make sure she understands, early on, that plagiarism is not tolerated. In blatant cases, a good response is to reject the proposal and consider informing the administration at the academic institution the student is affiliated with. The article <http://tesl-ej.org/ej10/a2.html> has some context to avoid surprises.
+Avoid spending time on proposals that were not tailored to your project by ignoring them. Some folks use the star feature to mark their favorites or to mark the proposals they are going to ignore. Stars are only visible to the user and can not be seen by others.
 
+Occasionally a GSoC contributor does not understand the importance of attribution when drawing on material from outside sources. Make sure they understand, early on, that plagiarism is not tolerated. The article <http://tesl-ej.org/ej10/a2.html> has some context to avoid surprises.
 
 ## Selection Strategies
 
 Probably the best that can be done in suggesting selection strategies is to provide a few simple ideas that organizations have used effectively in the past. Your organization will build its own selection process over time; these ideas are just a starting point:
 
-**Get outsider help.** Having a perspective from outside the "GSoC bubble" may help you see student proposals in a new light. Sometimes, even folks from outside your organization can provide useful review, especially if they have relevant technical expertise.
-
-**Use your mentors wisely.** The mentors are in the best position to select students and proposals for themselves. After all, it is they who will have to work with these students. Be careful, though, of mentors who may be less experienced in the ways that GSoC students and projects can go wrong. A few well-chosen war stories can be helpful in this situation.
-
-**Interact with the students during the proposal period.** There should be no remaining questions by the time students are slotted. Finding out that a student will not interact, or cannot interact well, is absolutely crucial.
+**Get outsider help.** Having a perspective from outside the "GSoC bubble" may help you see GSoC contributor proposals in a new light. Sometimes, even folks from outside your organization can provide useful review, especially if they have relevant technical expertise.
 
-**Don't be afraid to take charge.** At the end of the day, the org admin is responsible for the student and mentor selection decisions. If your org doesn't give you full veto power, or gives you grief about executive decisions, consider stepping down. Sometimes somebody has to make the final decision.
+**Use your mentors wisely.** The mentors are in the best position to select GSoC contributors and proposals for themselves. After all, it is they who will have to work with these GSoC contributors. Be careful, though, of mentors who may be less experienced in the ways that GSoC contributors and projects can go wrong. A few well-chosen war stories can be helpful in this situation.
 
+**Interact with the GSoC contributors during the proposal period.** There should be no remaining questions by the time GSoC contributors are slotted. Finding out that a GSoC contributor will not interact, or cannot interact well, is absolutely crucial.
 
+**Don't be afraid to take charge.** At the end of the day, the org admin is responsible for the GSoC contributor and mentor selection decisions. If your org doesn't give you full veto power, or gives you grief about executive decisions, consider stepping down. Sometimes somebody has to make the final decision.
diff --git a/pages/mentor/20-org_application.md b/pages/mentor/20-org_application.md
index 3869a112..7b0b1c30 100644
--- a/pages/mentor/20-org_application.md
+++ b/pages/mentor/20-org_application.md
@@ -8,53 +8,55 @@ sidebar: mentor_sidebar
 
 Successful applications can come in many forms. You should approach the organization application like you would a resume: this is the avenue through which you convince Google's program administrators that you are qualified for the job of mentoring students.
 
-The most important part of GSoC is providing the students an excellent experience over the summer, and Google chooses organizations that they feel confident can do this based on their application.
-
+The most important part of GSoC is providing the GSoC contributor an excellent experience over the summer, and Google chooses organizations that they feel confident can do this based on their application.
 
 ## The Ideas Page
 
-The ideas page is the most important part of the organization application. Please see the Ideas Page chapter of this guide for more information.
+The ideas page is the most important part of the organization application. Please see the Ideas Page chapter of this guide for more information. Be sure to adjust any project ideas from the previous year to adjust for the small (90 hour), medium (175 hour) and large (350 hour) scope. Google strongly encourages organizations to have a mix of medium and large (and if possible, small) projects.
 
+## What is Google looking for in a good organization application?
 
-## Past Success
+1. We can't say it enough - a solid Ideas list. (see above)
+2. Active community - your org needs to have a good community to support your GSoC contributor(s). You need at least 5 active people in your community. We won't accept orgs with just a few people that have submitted code to the org in the past year.
+3. Active project - have their been commits in the last few months?
+4. Solid understanding of GSoC and its goals - we can see this in your answers to the Org Application questions
+5. Established project - is the org at least 18 months old?
+6. Quality application - did you take the time to answer questions fully? Org apps with just 1 sentence answers show us you don't want to put in the time for the org app so why would Google trust you to devote the time needed to mentor a GSoC contributor?
+7. Most years Google is looking to include more organizations in specific fields. It will vary from year to year. For 2025, Google is looking to accept more organizations involved in security and AI/ML.
 
-One question Google consistently asks of an organization on the application is whether they have participated in previous years, and if so, what their students' pass/fail ratio was. While pass/fail ratio is but one indicator of the success of the previous year, it does weigh against other components of the application. Orgs who never fail a student are also red flags as that can indicate being too lenient on student evaluations. There is a healthy balance.
+## Past Success
 
+Each year Google will ask the ever important question: how many of your GSoC contributors from the previous year (or your most recent GSoC participation) are still active in your community? This is a question that is important for Google and for your organization to consider. As an organization are you engaging the GSoC contributors and getting them excited about staying in your community? Are you selecting the right GSoC contributors for your community who are interested in staying after their GSoC program ends? If your percentage of long term contributors from GSoC is consistently low what can your organization do to adjust? The program is about bringing contributors into your community and getting them to stay long after GSoC ends, thus keeping your ecosystem healthy. It is okay if your numbers are low, but your goal is to increase the number year after year, and adjustments are likely going to be necessary from your organization to successfully retain more of your GSoC contributors long term.
 
 ## New Orgs vs. Returning Orgs
 
-Every year Google tries to make room for new organizations in the open source world who can provide a different perspective or different opportunities to the students who participate in GSoC. This can often mean rejecting an org that has successfully participated in years past to allow space for new organizations. Often these decisions are very difficult for Google to make, because they don't have much to do with the returning orgs' success in previous years.  Also sometimes Google chooses to let an organization that has been participating for many years have a year off to let a new organization participate. It doesn't mean that Google is upset wit that veteran organization, there just needs to be new blood and things need to get mixed up every now and then. The veteran should certainly apply again for the next year's program.
-
+Every year Google tries to make room for new organizations in the open source world who can provide a different perspective or different opportunities to the GSoC contributors. This can often mean rejecting an org that has successfully participated in years past to allow space for new organizations. Often these decisions are very difficult for Google to make, because they don't have much to do with the returning orgs' success in previous years.  Also sometimes Google chooses to let an organization that has been participating for many years have a year off to let a new organization participate. It doesn't mean that Google is upset with that veteran organization, there just needs to be new blood and things need to get mixed up every now and then. The veteran organization should certainly apply again for the next year's program.
 
 ## What Not to Do
 
-Incomplete applications are common and result in an automatic rejection by Google. Don't submit an Ideas List or a document Google administrators don't have access to. Do not make your Ideas list a link to a list of bug tracker issues, that will be a rejection. Google doesn't have the time or capacity to iterate with you on your application. Take the time to create a thoughtful proposal.
+Incomplete applications are common and result in an automatic rejection by Google. Don't submit an Ideas List or a document Google administrators don't have access to. Do not make your Ideas List a link to a list of bug tracker issues, that will be a rejection. Google doesn't have the time or capacity to iterate with you on your application. Take the time to create a thoughtful proposal. Don't miss the application deadline, there are no extensions even if you just forgot to hit Save.
 
+## Just Because You Did Everything Right
 
-## Just Because You Did Everything Right...
-
-...doesn't mean you'll be accepted. Every year Google receives many more applications for organizations that want to participate in GSoC than it has capacity to accommodate. Some of the decisions about which organizations are accepted and which aren't come down entirely to space available in the program. Google receives 475+ applications from open source organizations each year that wish to be a part of GSoC and usually only accept between 180-200 organization applications. Thus more than 50% of the organizations that apply each year will be rejected.
-
+...doesn't mean you'll be accepted. Every year Google receives many more applications for organizations that want to participate in GSoC than it has capacity to accommodate. Some of the decisions about which organizations are accepted and which aren't come down entirely to space available in the program. Google receives 450+ applications from open source organizations each year that wish to be a part of GSoC and usually only accept around 150-200 organization applications. Thus more than 50% of the organizations that apply each year will be rejected.
 
 ## A Note on Umbrella Orgs
 
-Google's program administrators actually look quite fondly on the umbrella organizations that participate each year. It serves a dual purpose: it allows Google to accept more organizations in the "space" of just one, and also gives an opportunity to accept a marginally-topical org by putting it under the umbrella of a related org.
+Umbrella organizations are organizations that have many sub-projects underneath them. Think Python Software Foundation, Apache Software Foundation, etc. Umbrella orgs serve a dual purpose: they allows Google to accept more organizations in the "space" of just one, and also gives an opportunity to accept a marginally-topical org by putting it under the umbrella of a related org. Also the heavy load of organization administration is handled by the often experienced and veteran organization administrators of the umbrella org, allowing the smaller sub-project to focus on mentoring and their GSoC contributors.
 
 If your application is rejected, the following you may want to consider reaching out to an accepted umbrella org that might be able to accommodate you.
 
-
 ## What's On the Application?
 
 The questions vary from year to year, but will be similar to:
 
 * Why does your org want to participate in GSoC?
-* How many potential mentors have agreed to mentor this year?
-* How will you keep mentors engaged with their students?
-* How will you help your students stay on schedule to complete their projects?
-* How will you get your students involved in your community during GSoC?
-* How will you keep students involved with your community after GSoC?
+* What would your organization consider to be a successful GSoC for your org?
+* How will you keep mentors engaged with their GSoC contributors?
+* How will you help your GSoC contributors stay on schedule to complete their projects?
+* How will you keep your GSoC contributors involved in your community during and after GSoC?
 * Has your org been accepted as a mentor org in GSoC?
-* What year was your project started?
+* If so, when and how many GSoC contributors are still actively involved in your community today?
 * Where does your source code live?
 * Link to your Ideas List (this is the most important part of the application!)
 
diff --git a/pages/mentor/21-managing_your_mentors.md b/pages/mentor/21-managing_your_mentors.md
index 574cbe1f..3c4b6df2 100644
--- a/pages/mentor/21-managing_your_mentors.md
+++ b/pages/mentor/21-managing_your_mentors.md
@@ -8,61 +8,50 @@ sidebar: mentor_sidebar
 
 As an org admin, your primary responsibilities are managing the GSoC program administrative requirements and helping your mentors effectively mentor.  Below are some guidelines to help you accomplish both objectives.
 
-
 ## Establish a Private Communication Channel
 
-It is important for mentors and org admins to have a communication channel that does not involve students, so org admins can speak candidly with mentors. This usually takes the form of a private mailing list or IRC channel, but any agreed-upon medium will work.
-
+It is important for mentors and org admins to have a communication channel that does not involve GSoC contributors, so org admins can speak candidly with mentors. This usually takes the form of a private mailing list or IRC channel, but any agreed-upon medium will work.
 
 ## Managing across Timezones
 
-Org admins should have a list of mentors and students along with their timezones and preferred contact information and availability. This is essential for umbrella organizations, which sometimes have so many people spread across so many countries and time zones that it is impossible for an org admin to keep track.
+Org admins should have a list of mentors and GSoC contributors along with their timezones and preferred contact information and availability. This is essential for umbrella organizations, which sometimes have so many people spread across so many countries and time zones that it is impossible for an org admin to keep track.
 
 GSoC is often the first time people ever have to collaboratively work with others across many timezones, so it is worth taking time in the beginning of the summer to figure out these details. The fact that Daylight Savings Time is different depending on where people are complicates things even more. Usually it is best to set times in UTC so that DST will not complicate things. The World Clock website (<http://www.timeanddate.com/worldclock/>) is also a good resource for determining the time in a certain location.
 
-
 ## Setting Expectations
 
-As an org admin, you need to rely on your mentors to manage the day-to-day activities related to student projects. This means you should have a discussion before students are accepted--if possible before you even apply for GSoC--about how you are going to handle some basic logistical items that are essential for a smoothly running and effective program.
-
-
-### Set up-front guidelines on how students, projects and mentors are selected
-
-Occasionally, you'll find yourself with mentors for projects with no students and good project ideas with no mentors. Figure out up front how you plan to evaluate and accept students, projects and mentors. Make sure that your open source community concurs and the guidelines are clearly posted in your community GSoC documentation. See the chapter on *Selecting Students and Mentors *for details.
+As an org admin, you need to rely on your mentors to manage the day-to-day activities related to GSoC contributor projects. This means you should have a discussion before GSoC contributors are accepted--if possible before you even apply for GSoC--about how you are going to handle some basic logistical items that are essential for a smoothly running and effective program.
 
+### Set up-front guidelines on how GSoC contributors, projects and mentors are selected
 
-### Determine a schedule and format for regular student project updates
+Occasionally, you'll find yourself with mentors for projects with no GSoC contributors and good project ideas with no mentors. Figure out up front how you plan to evaluate and accept GSoC contributors, projects and mentors. Make sure that your open source community concurs and the guidelines are clearly posted in your community GSoC documentation. See the chapter on *Selecting GSoC contributors and Mentors* for details.
 
-Regular student progress reports to the open source project community are a great tool for keeping your development community engaged and helpful to the students. It also helps provide documentation if there is any doubt about a student's progress, and can help your community identify problem areas for newcomers. Weekly reports via a blog or mailing list post are best; at the very least ask for bi-weekly student reports to your community. Discuss report format and submission timelines before the student application period opens and make sure your potential students understand their reporting responsibilities.
+### Determine a schedule and format for regular GSoC contributor project updates
 
-Make sure the mentors understand they are primarily responsible for encouraging their students to submit regular reports.
+Regular GSoC contributors progress reports to the open source project community are a great tool for keeping your development community engaged and helpful to the GSoC contributors. It also helps provide documentation if there is any doubt about a GSoC contributor's progress, and can help your community identify problem areas for newcomers. Weekly reports via a blog or mailing list post are best; at the very least ask for bi-weekly GSoC contributor reports to your community. Discuss report format and submission timelines before the GSoC contributors application period opens and make sure your potential GSoC contributors understand their reporting responsibilities.
 
+Make sure the mentors understand they are primarily responsible for encouraging their GSoC contributors to submit regular reports.
 
 ### Establish up-front guidelines for mentor time involvement
 
-How often should mentors meet with their students? What happens if a mentor needs to be unavailable for several weeks during GSoC? Make sure the mentors understand expected time commitments before they are assigned to a student, and how to arrange for backup if they need to go missing for a bit.
-
+How often should mentors meet with their GSoC contributors? What happens if a mentor needs to be unavailable for several weeks during GSoC? Make sure the mentors understand expected time commitments before they are assigned to a GSoC contributor, and how to arrange for backup if they need to go missing for a bit.
 
 ### Clearly communicate mentor GSoC administrative responsibilities
 
-Mentors at the very minimum are responsible for submitting timely student evaluations at midterms and finals. Make sure your mentor team is clear about when they need to submit evaluations and what to do if they are not available to submit the evaluations.
-
-
-### Create a decision process for determining if a student should pass or fail
+On the administrative front, mentors at the very minimum are responsible for submitting timely GSoC contributor evaluations at the midterm and final. Make sure your mentor team is clear about when they need to submit evaluations and what to do if they are not available to submit the evaluations.
 
-Unfortunately, at some point your organization is probably going to encounter a situation where you need to determine if you should fail a student at midterms or finals. Talk to your mentors before the GSoC program begins about criteria for passing and failing a student. Communicate clearly who makes the final decision about whether a student pass or fails.
+### Create a decision process for determining if a GSoC contributor should pass or fail
 
+Unfortunately, at some point your organization is probably going to encounter a situation where you need to determine if you should fail a GSoC contributor at the midterm or final. Talk to your mentors before the GSoC program begins about criteria for passing and failing a GSoC contributor. Communicate clearly who makes the final decision about whether a GSoC contributor pass or fails.
 
 ## Sorting Out Conflicts
 
-At some point in your org admin career you are going to need to step in to help resolve conflicts. Sometimes these are mentor-student conflicts, cross-project conflicts or mentor-mentor conflicts; they may be something completely unexpected.  Here are a few guidelines to help you find the best-approach for resolution:
+At some point in your org admin career you are going to need to step in to help resolve conflicts. Sometimes these are mentor-GSoC contributor conflicts, cross-project conflicts or mentor-mentor conflicts; they may be something completely unexpected.  Here are a few guidelines to help you find the best-approach for resolution:
 
-*   Get involved early, before things spiral out of control.
-*   Discuss the conflict privately and separately with those involved.
-*   Whenever possible don't take sides, but rather attempt to function as a mediator.
-*   Remember that you are a senior representative of your open source community within the larger GSoC program community.
-*   Ask for advice from the GSoC program staff.
+* Get involved early, before things spiral out of control.
+* Discuss the conflict privately and separately with those involved.
+* Whenever possible don't take sides, but rather attempt to function as a mediator.
+* Remember that you are a senior representative of your open source community within the larger GSoC program community.
+* Ask for advice from the GSoC program staff.
 
 If you've done a good job of setting expectations with your mentors, conflict resolution *should* be fairly straight-forward.
-
-
diff --git a/pages/mentor/22-student_-_mentor_facilitation.md b/pages/mentor/22-student_-_mentor_facilitation.md
index a0fac7cf..d6a1c735 100644
--- a/pages/mentor/22-student_-_mentor_facilitation.md
+++ b/pages/mentor/22-student_-_mentor_facilitation.md
@@ -1,19 +1,17 @@
 ---
-title: Student - Mentor Facilitation
+title: GSoC contributor - Mentor Facilitation
 section: Org Admin
 order: 22
 permalink: mentor/student-mentor-facilitation.html
 sidebar: mentor_sidebar
 ---
 
-The key to a successful GSoC experience is good communication. It is both a challenge and an opportunity. You are often dealing with students who have never participated in open source or collaborative development. Your mentors may be volunteering time they don't have. Neither may have worked across the time and cultural spans commonly found in GSoC.
+The key to a successful GSoC experience is good communication. It is both a challenge and an opportunity. You are often dealing with GSoC contributors who have never participated in open source or collaborative development. Your mentors may be volunteering time they don't have. Neither may have worked across the time and cultural spans commonly found in GSoC.
 
-It is up to the org admin to stress communication strategies and expectations for both students and mentors.
-
-*   Make sure your mentors set expectations for time commitment, meetings, reports and code check-ins, and that these have been clearly communicated (if not collaboratively developed) with their students.
-*   Make sure both mentors and students have established more than one channel of communication with each other.
-*   Create internal contact groups for all your mentors and all your students. Use these email lists for general statements and advice regarding who should be doing what and when, and for asking, "Do you know where your student [or mentor] is?"
-
-The number one reason why projects fail is poor communication. It is often the first sign of a project in trouble. Poor communication may originate as much with the mentor as with the student.  A big part of your role as org admin is to lay out guidelines and advice at the start of the program, and then to keep track of progress. The org admin should be aware of communication problems early on. The only way to make sure you know what's going on is to periodically check-in with individual students and mentors. The week before evaluations is a good time to make contact and ensure there are no surprises coming.  You should also stress to your mentors and students that they should contact you whenever there is a communication breakdown.
+It is up to the org admin to stress communication strategies and expectations for both GSoC contributors and mentors.
 
+* Make sure your mentors set expectations for time commitment, meetings, reports and code check-ins, and that these have been clearly communicated (if not collaboratively developed) with their GSoC contributors.
+* Make sure both mentors and GSoC contributors have established more than one channel of communication with each other.
+* Create internal contact groups for all your mentors and all your GSoC contributors. Use these email lists for general statements and advice regarding who should be doing what and when, and for asking, "Do you know where your GSoC contributor [or mentor] is?"
 
+The number one reason why projects fail is poor communication. It is often the first sign of a project in trouble. Poor communication may originate as much with the mentor as with the GSoC contributor.  A big part of your role as org admin is to lay out guidelines and advice at the start of the program, and then to keep track of progress. The org admin should be aware of communication problems early on. The only way to make sure you know what's going on is to periodically check-in with individual GSoC contributors and mentors. The week before evaluations is a good time to make contact and ensure there are no surprises coming.  You should also stress to your mentors and GSoC contributors that they should contact you whenever there is a communication breakdown.
diff --git a/pages/mentor/23-other_possible_issues.md b/pages/mentor/23-other_possible_issues.md
index 02455636..d2f867d5 100644
--- a/pages/mentor/23-other_possible_issues.md
+++ b/pages/mentor/23-other_possible_issues.md
@@ -12,16 +12,14 @@ Here are some things that might go wrong during the program, and how you can han
 
 **Solution: Call for backup.**
 
-Sometimes "life" happens and things don't go according to plan. It is best to come up with a plan at the beginning of the summer to deal with a mentor that suddenly don't have as much free time as he thought he would, or even worse, a mentor that goes missing.
+Sometimes "life" happens and things don't go according to plan. It is best to come up with a plan at the beginning of the summer to deal with a mentor that suddenly doesn't have as much free time as they thought they would, or even worse, a mentor that goes missing.
 
-Having additional mentors assigned to each student is a very good idea, and helps with situations where the primary mentor is not available. Google does not have a policy on additional mentors, so this is something that an org admin needs to decide to have--the earlier the better.
+Having additional mentors assigned to each GSoC contributor is a very good idea, and helps with situations where the primary mentor is not available. Google does not have a policy on additional mentors, so this is something that an org admin needs to decide to have--the earlier the better.
 
 **Issue: Communication between participants breaks down.**
 
 **Solution: Stage an intervention**
 
-First off, it is important to create a schedule for communication before coding begins. The org admin and mentors should agree on a frequency of communication that is appropriate for communicating with students and each other. This should be at least once per week, because it is very easy to let a few weeks slip by and then realize that the timeline for the project is nearly impossible to follow.
+First off, it is important to create a schedule for communication before coding begins. The org admin and mentors should agree on a frequency of communication that is appropriate for communicating with GSoC contributors and each other. This should be at least once per week, because it is very easy to let a few weeks slip by and then realize that the timeline for the project is nearly impossible to follow.
 
 If, in spite of all your best efforts, you have to deal with a communication breakdown, you will need to step in and restart communication yourself. Meet separately with the parties using the most personal medium available, and then make sure they meet with each other. Reestablish a regular schedule of communication, and find a way to monitor it.
-
-
diff --git a/pages/mentor/24-end_of_year_report.md b/pages/mentor/24-end_of_year_report.md
index 018e0a92..45e7f90c 100644
--- a/pages/mentor/24-end_of_year_report.md
+++ b/pages/mentor/24-end_of_year_report.md
@@ -8,9 +8,6 @@ sidebar: mentor_sidebar
 
 Phew! You made it. There may have been some rough spots along the way, perhaps even some failures, but you made it. Your work is *almost* done. It's time to take a look back and produce an End-of-Year Report. Make it fun and it'll be painless. Heck, people might even read it!
 
-The report should be written for a general audience, so include an introduction to your organization and your main goals. You might mention how many years you've participated in GSoC and the number of students you've mentored. Depending on how many projects you ran, you should highlight what they were about, how much code was written, and code integration plans. Were there any special events or face-to-face meetings over the summer? Any positive surprises?
-
-In the end, the report is all about the students. Be sure to mention any blogs that were maintained by your students, and any public references to their work. Links to screenshots or video demonstrations are quite effective. Including student quotes is a fun way to represent not only their experience but also your organization, through the eyes of new contributors.
-
-You can also tailor the report to be good blog fodder for the Google Open Source blog post your organization administrators might want to submit to Google program administrators. That blog post should have some fun stories about the work the student did or quotes from the students or mentors to make it more interesting to the reader.
+The report should be written for a general audience, so include an introduction to your organization and your main goals. You might mention how many years you've participated in GSoC and the number of GSoC contributors you've mentored. Depending on how many projects you ran, you should highlight what they were about, how much code was written, and code integration plans. Were there any special events or face-to-face meetings over the summer? Any positive surprises?
 
+In the end, the report is all about the GSoC contributors. Be sure to mention any blogs that were maintained by your GSoC contributors, and any public references to their work. Links to screenshots or video demonstrations are quite effective. Including GSoC contributor quotes is a fun way to represent not only their experience but also your organization, through the eyes of new contributors.
diff --git a/pages/mentor/25-about_this_manual.md b/pages/mentor/25-about_this_manual.md
index 34bc372c..88be1ce5 100644
--- a/pages/mentor/25-about_this_manual.md
+++ b/pages/mentor/25-about_this_manual.md
@@ -12,14 +12,14 @@ maintenance of the manual is an ongoing process to which you may wish to
 contribute. A second sprint occurred in 2010 to update the manual (adding the
 Org Admin section) and write the Students Guide ("Flipping Bits not
 Burgers"). Additional brief edits occurred February 2017 and November 2019 to update and reflect the
-new website and program changes.
-
+new website and program changes. A more comprehensive edit occurred in November 2021 to reflect the
+changes for the upcoming 2022 program updates and the new webapp by the GSoC Program Administrator,
+Stephanie Taylor.
 
 ## How to Contribute to This Guide
 
 Read the CONTRIBUTING file in the source repository.
 
-
 ## About the Authors
 
 Except where noted, the following individuals were part of both the 2009 and 2010 GSoC Book Sprint. We thank them for their tireless efforts to create this first-of-its-kind volume.
@@ -66,7 +66,6 @@ Malveeka is currently a graduate student in the CS dept at UC, San Diego. She pa
 
 <http://cseweb.ucsd.edu/~mtewari/>
 
-
 ## 2009 Participants
 
 **Olly Betts**
@@ -81,7 +80,6 @@ Leslie held various roles at Google before joining the Open Source Programs Offi
 
 <http://www.hawthornlandings.org>
 
-
 ## Facilitation (2009 & 2010)
 
 The Book Sprints were facilitated by:
@@ -90,7 +88,4 @@ The Book Sprints were facilitated by:
 
 Adam is the founder of FLOSS Manuals and project manager for Booki. FLOSS Manuals is a community of 1500 (at the time of writing) volunteers that create quality free documentation about free software. FLOSS Manuals is pioneering the Book Sprint methodology that enables the development of well written manuals on free software in 2-5 days. Adam has facilitated over 15 Book Sprints on Free Software including Inkscape, OLPC, Sugar, CiviCRM, Firefox, Introduction to the Command Line, Digital Foundations (conversion to free software examples), Ogg Theora, How to Bypass Internet Censorship, Open Translation Tools, PureData, Video Subtitling and now the Google Summer of Code Mentors Guide. Adam is also the Project Manager for the development of 'Booki' - the free software Collaborative Authoring Platform (see below).
 
-adam@flossmanuals.net
-
-
-
+<adam@flossmanuals.net>
diff --git a/pages/mentor/26-the_quick_guide.md b/pages/mentor/26-the_quick_guide.md
index 0552c777..03454a7b 100644
--- a/pages/mentor/26-the_quick_guide.md
+++ b/pages/mentor/26-the_quick_guide.md
@@ -6,26 +6,25 @@ permalink: mentor/the-quick-guide.html
 sidebar: mentor_sidebar
 ---
 
-The process begins with proposing projects and selecting students over about a four week period. This is followed by 3-4 weeks of community bonding. The coding phase runs for twelve weeks.
-
-*   During the student selection phase the mentor will be responsible for helping find a fit between project, student proposal and mentor. This will include defining the proposal process, assisting in the evaluation of proposals, querying the students, providing them feedback about their proposals and ultimately finding a student proposal to mentor.
-*   During the community bonding phase, the mentor and student will further define the student's project and prepare for development. An important part of this phase, as the name implies, is to get the student connected with both the mentoring organization and the larger open source community.
-*   During the coding phase the student will be implementing the project. The mentor will be providing advice not just on the technical aspects of development, but on issues related to the interaction of the student's work with the organization. At midterm the mentor will evaluate the student's progress to determine whether the student will continue with the project and be issued a payment by Google.
-*   During the final phase the mentor will help the student submit their code to Google. The mentor will also perform an evaluation of the student's work to determine whether Google should issue a final payment.
+The process begins with proposing projects and selecting GSoC contributors over about a four week period. This is followed by 3 weeks of community bonding. The standard coding period runs for twelve weeks (with optional extensions up to 22 weeks available starting in 2022).
 
+* During the GSoC contributor selection phase the mentor will be responsible for helping find a fit between project, GSoC contributor proposal and mentor. This will include defining the proposal process, assisting in the evaluation of proposals, querying the GSoC contributors, providing them feedback about their proposals and ultimately finding a GSoC contributor proposal to mentor.
+* During the community bonding phase, the mentor and GSoC contributor will further define the GSoC contributor's project and prepare for development. An important part of this phase, as the name implies, is to get the GSoC contributor connected with both the mentoring organization and the larger open source community.
+* During the coding phase the GSoC contributor will be implementing the project. The mentor will be providing advice not just on the technical aspects of development, but on issues related to the interaction of the GSoC contributor's work with the organization. At midterm the mentor will evaluate the GSoC contributor's progress to determine whether the GSoC contributor will continue with the project and be issued a payment by Google.
+* During the final phase the mentor will help the GSoC contributor submit their code to their organization. The mentor will also perform an evaluation of the GSoC contributor's work to determine whether Google should issue a final payment.
 
 ## Quick Tips on Effective Mentoring
 
 The tips in this section are no substitute for reading this book.  However, they may serve as an introduction to the material herein.
 
-**Project Definition**: An ideas page is the starting point for project definition.  You should include projects that you are interested in mentoring for the summer and that appeal to students and to your organization.
+**Project Definition**: An ideas page is the starting point for project definition.  You should include projects that you are interested in mentoring for the summer and that appeal to GSoC contributors and to your organization.
 
-**Selecting Students**: Students come with many motivations; try to understand why your applicant is applying. It is better to give up a student slot than to select a student whose performance is likely to be poor.
+**Selecting GSoC contributors**: GSoC contributors come with many motivations; try to understand why your applicant is applying. It is better to give up a GSoC contributor slot than to select a GSoC contributor whose performance is likely to be poor.
 
-**Communication**: Engage with your student as early as possible. Integrate the student into your community and its communication channels. Make sure that communication with your student is frequent and regular.
+**Communication**: Engage with your GSoC contributor as early as possible. Integrate the GSoC contributor into your community and its communication channels. Make sure that communication with your GSoC contributor is frequent and regular.
 
-**Collaboration**: Start by working with your student to set solid expectations and goals for the project. Develop a detailed project plan, with deadlines and milestones. Be prepared for slippage, and be willing to revise the plan as necessary, especially at midterm. Student learning is a primary goal of GSoC, so try to provide a learning experience.
+**Collaboration**: Start by working with your GSoC contributor to set solid expectations and goals for the project. Develop a detailed project plan, with deadlines and milestones. Be prepared for slippage, and be willing to revise the plan as necessary, especially at midterm. GSoC contributor learning is a primary goal of GSoC, so try to provide a learning experience.
 
-**Evaluation**: Keep your student evaluations objective; base them on your project plan.  Keep in mind that it is better to fail a student earlier rather than later--data shows that students doing poorly at midterm rarely complete a GSoC project.  Make sure your students hear your evaluations: deliver praise in public, and criticism in private.
+**Evaluation**: Keep your GSoC contributor evaluations objective; base them on your project plan.  Keep in mind that it is better to fail a GSoC contributor earlier rather than later--data shows that GSoC contributors doing poorly at midterm rarely complete a GSoC project.  Make sure your GSoC contributors hear your evaluations: deliver praise in public, and criticism in private.
 
-If you follow the above advice, and the rest of the advice given in this book, you have a good chance to have a successful experience. Positive outcomes might include recruiting a permanent developer to your community, developing a lifelong relationship with your student, and helping the open source community grow and thrive.
+If you follow the above advice, and the rest of the advice given in this book, you have a good chance to have a successful experience. Positive outcomes might include recruiting a permanent developer to your community, developing a lifelong relationship with your GSoC contributor, and helping the open source community grow and thrive.
diff --git a/pages/mentor/27-the_history_of_gsoc.md b/pages/mentor/27-the_history_of_gsoc.md
index 08f4b9f0..abf9fe40 100644
--- a/pages/mentor/27-the_history_of_gsoc.md
+++ b/pages/mentor/27-the_history_of_gsoc.md
@@ -6,18 +6,18 @@ permalink: mentor/the-history-of-gsoc.html
 sidebar: mentor_sidebar
 ---
 
-Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. Larry Page, one of Google's co-founders, was pondering the age-old problem of scholastic backsliding: students work hard and learn a great deal during the academic year, but without the right employment opportunities and other pursuits outside of school, technical skills atrophy rather than get honed and expanded. Larry wanted Google to help solve this problem.
+Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. Larry Page, one of Google’s co-founders, was pondering the age-old problem of scholastic backsliding: students work hard and learn a great deal during the academic year, but without the right employment opportunities or other pursuits outside of school, technical skills atrophy rather than get honed and expanded. Larry wanted Google to help solve this problem.
 
-The obvious solutions failed on geographical grounds. If a student wasn't in the optimal location, obtaining a useful internship could be difficult or impossible. Finances were also a problem; many internships are low paying or entirely unpaid, making it difficult for students to take the right job while still paying the bills. Finally, even if a job was available in a technical field, it would not necessarily introduce a student to the broad set of skills required to do software development well. For example, creating a website for a local non-profit requires technical skill and would no doubt be personally gratifying, but wouldn't necessarily require using an IDE, checking into source control, or creating tests.
+The obvious solutions failed on geographical grounds. If a student wasn’t in the optimal location, obtaining a useful internship could be difficult if not impossible. Finances were also a problem; many internships are low paying or entirely unpaid, making it difficult for students to take the right job while still paying the bills. Finally, even if a job was available in a technical field, it would not necessarily introduce a student to the broad set of skills required to do software development well. For example, creating a website for a local non-profit requires technical skill and would no doubt be personally gratifying, but wouldn’t necessarily require using an IDE, checking into source control, or creating tests.
 
-The perfect answer? Encourage students to participate in open source projects. Open source development occurs online, solving the geography problem and giving students the chance to work in a globally distributed team. Working on an open source project provides exposure to the entire software development process and toolchain. Students enjoy the benefit of having a body of reference work available to future employers and university admissions committees. Even better, students get the chance to work on a codebase under active development rather than a lab project or other single-use assignment.
+The perfect answer came from encouraging students to participate in open source projects. Open source development occurs online, both solving the geography problem and giving students the chance to work in a globally distributed team. Working on an open source project provides exposure to the entire software development process and tool chain. Students could enjoy the added benefit of having a body of reference work available to future employers or committees. Even better, students would get the chance to work on a code base under active development rather than a lab project or other single use assignment.
 
-The Google Summer of Code program provides a cash stipend from Google to students for work with recognized open source communities. This stipend allows students to focus on their development work rather than getting a job unrelated to their academic pursuits. A key piece of the puzzle is finding projects that are excited to find new contributors and to provide helpers to get new student contributors up to speed both technically and socially.
+A cash stipend from Google allowed students to focus on their development work rather than getting a job unrelated to their academic pursuits. The final part of the puzzle was finding projects who were excited to find new contributors and to provide helpers to get these new folks up to speed both technically and socially. The first year 40 projects participated; 400 students began the experiment.
 
-The first year 40 projects participated--400 students began the experiment.
-
-In 2019, the 15th Google Summer of Code wrapped up with more than 89% of the 1,267 student participants in the program successfully completing their projects. Best of all, most of the 686 organizations participating over the past 15 years reported that the program helped them find new community members and active committers.
-
-You can find more information about each year of Google Summer of Code on the program statistics page on the History tab of the GSoC website: <https://developers.google.com/open-source/gsoc/resources/stats>
+In 2021, the seventeenth Google Summer of Code wrapped up with more than 94% of the 1198 student participants in the program successfully completing the program. Best of all, most of the organizations participating over the past seventeen years reported that the program helped them find new community members and active committers. 99% of 2021 students said they planned to continue to contribute to open source post-GSoC.
 
+In 2022, we are opening the program to non-student developers as well and we are excited to see what great things our new GSoC contributors will do with our open source organizations. We also have multiple size project options available for folks, with the understanding not everyone can dedicate 350 hours to an open source project during GSoC so there will also be 175 hour projects available for GSoC contributors to work on in 2022. The final update to the program is more flexibility around the schedule for a GSoC contributor project. Instead of everyone having to complete the project in 12 weeks, GSoC contributors and their mentors can decide to extend the end date of their project to better fit the GSoC contributor’s commitments for the summer. We look forward to these updates helping even more people excited to learn about open source under the guidance of dedicated mentors participate in GSoC.
 
+[Past participants](https://summerofcode.withgoogle.com/archive)
+and [statistics](https://developers.google.com/open-source/gsoc/resources/stats)
+are tracked available on the program website.
diff --git a/pages/mentor/28-additional_resources.md b/pages/mentor/28-additional_resources.md
index 4fa391a3..129a2c12 100644
--- a/pages/mentor/28-additional_resources.md
+++ b/pages/mentor/28-additional_resources.md
@@ -8,26 +8,24 @@ sidebar: mentor_sidebar
 
 We've collected our favorite and most useful resources specific to GSoC here.
 
-
 ## General Resources
 
-If your organization has participated in GSoC previously, chances are there are mailing lists already set up and useful information in their archives; take a moment to look through them, especially around the launch times (February to March), community bonding period (April to May) and evaluation times (mid-July and end of August), for more details. The archives of the program mailing lists, particularly the private mentors list (below), are also quite useful.
+If your organization has participated in GSoC previously, chances are there are mailing lists already set up and useful information in their archives; take a moment to look through them, especially around the launch times (February to March), community bonding period (May) and evaluation times (mid-July and end of August), for more details. The archives of the program mailing lists, particularly the private mentors list (below), are also quite useful.
 
 No matter what, you want to take a look at the Program Rules each year to make sure you have a good idea of the rules for the program for both yourself and your students. There's a wealth of information included in the FAQs each year, even for experienced participants. You can always find the latest information, including a link to the FAQs, at <https://developers.google.com/open-source/gsoc/faq>.
 
 Additionally, these resources are quite helpful:
 
-**Program IRC Channel**: Several knowledgeable folks (mentors, org admins, former students, current students) hang out in #gsoc on Freenode and would be happy to give you a pointer in the right direction.
+**Program IRC Channel**: Several knowledgeable folks (mentors, org admins, former students, current students) hang out in #gsoc on Libera.Chat and would be happy to give you a pointer in the right direction.
 
 **Blog Posts**: You can find material related to GSoC on the Google Open Source Blog at <http://google-opensource.blogspot.com>. Your project may have a blog or newsletter where GSoC information was published in the past, as well.
 
-**Knowledge Base**: If you're looking for advice for mentors or students, program promotional materials, presentations about GSoC, etc., start with the program site <https://g.co/gsoc>, particularly the Resources section.
+**Knowledge Base**: If you're looking for advice for mentors or GSoC contributors, program promotional materials, presentations about GSoC, etc., start with the program site <https://g.co/gsoc>, particularly the Resources section.
 
-**Mentor Summit Wiki**: Google has traditionally held an annual mentor summit after GSoC wraps up each year. During the summit, many great discussions are held on all sorts of topics regarding the program and open source overall. 
+**Mentor Summit**: Google has traditionally held an annual mentor summit after GSoC wraps up each year. During the summit, many great discussions are held on all sorts of topics regarding the program and open source overall.
 
 **List of Organizations**: You can see a list of the mentoring organizations that participated in previous years of the program by going to the program site and looking at the Archive site: <https://developers.google.com/open-source/gsoc/past-summers>
 
-
 ## Mailing Lists
 
 There are three program mailing lists.
@@ -42,7 +40,6 @@ There are three program mailing lists.
 
 **Mentors List**: Private, invite-only list; mentors are subscribed to the list after their organization is accepted into the program and they opt in to the list during registration. This list is higher traffic at the beginning of the program and around the times of evaluations. Some great advice can be found on this list and in the archives, but it can also be noisy at times.
 
-
 ## Books
 
 **Producing Open Source**
@@ -51,11 +48,10 @@ Written by Karl Fogel. Excellent guide to Open Source development. Its available
 
 <http://producingoss.com/>
 
-**Google Summer of Code Students Guide**
+**Google Summer of Code Contributor/Student Guide**
 
 <https://google.github.io/gsocguides/student/>
 
-
 ## Associated Projects
 
 **Teaching Open Source**
@@ -64,11 +60,8 @@ Written by Karl Fogel. Excellent guide to Open Source development. Its available
 
 irc : freenode #teachingopensource
 
-
 ## What to Do When the Unexpected Happens?
 
-**Contact your Organization Administrator**: He or she can help you figure out what to do next or contact Google for more help.
-
-**Talk to Google's Program Administrators**: They have plenty of experience with all the corner cases and strange issues that can arise during GSoC. Email gsoc-support@google.com for help.
-
+**Contact your Organization Administrator**: They can help you figure out what to do next or contact Google for more help.
 
+**Talk to Google's Program Administrators**: They have plenty of experience with all the corner cases and strange issues that can arise during GSoC. Email <gsoc-support.com> for help.
diff --git a/pages/mentor/29-glossary.md b/pages/mentor/29-glossary.md
index 1cd4aad2..720a3cf1 100644
--- a/pages/mentor/29-glossary.md
+++ b/pages/mentor/29-glossary.md
@@ -11,114 +11,90 @@ sidebar: mentor_sidebar
 
 The shortest way in the geek world to say "I agree with this" or "This is a great idea". It is often used when others have already fleshed out the details and a consensus of how many agree/disagree with the sentiment. It is worth noting to your students if your project uses this as a voting signal so they do not accidentally comment on issues when, as newbies, they should be observing rather than commenting/voting.
 
-
 ## -1
 
 The opposite of +1. Often accompanied by an explanation why, if you are lucky.
 
-
 ## Committer
 
 An individual who has special rights in an open source project. While the scope of this term varies by project, the general idea is that this individual is able to check in source code to the project's main repository.
 
-
 ## Community Bonding Period
 
-The period of time between when accepted students are announced for a particular year of GSoC and the time these students are expected to start coding. This time is an excellent one to introduce students to the community, get them on the right mailing lists, etc. See the "Mind the Gap" section for more details.
-
+The period of time between when accepted GSoC contributors are announced for a particular year of GSoC and the time these GSoC contributors are expected to start coding. This time is an excellent one to introduce students to the community, get them on the right mailing lists, etc. See the "Mind the Gap" section for more details.
 
 ## DVCS
 
 Distributed version control system. A version control system that does not require talking to a centralized server.
 
-
 ## FLOSS
 
 Free/Libre Open Source Software. Likely the most inclusive acronym to describe the software produced for GSoC.
 
-
 ## GSoC
 
 Google Summer of Code
 
-
 ## IDE
 
 Integrated Development Environment
 
-
 ## IM
 
 Instant Messenger
 
-
 ## IRC
 
 Internet Relay Chat
 
-
 ## ISP
 
 Internet Service Provider
 
-
 ## JFDI
 
 Just Fabulously Do It. Use your imagination. Ask for forgiveness, not for permission. :)
 
-
 ## Mentor
 
 Someone who helps a student with their project proposal. See the What is GSoC section for more details.
 
-
 ## Organization
 
-An open source, free software or technology-related project that mentors students for Google Summer of Code. Also known as a mentoring organization.
-
+An open source, free software or technology-related project that mentors GSoC contributors for Google Summer of Code. Also known as a mentoring organization.
 
 ## Organization Admin (Org Admin)
 
 Cat herders for each open source project participating in the program. Often abbreviated to org admin. See the What is GSoC section for more details.
 
-
 ## Program Administrator
 
 Google employees who run the program. See the What is GSoC section for more details.
 
-
 ## RTFM
 
 **R**ead **T**he **F**LOSS **M**anual ;)
 
-
 ## Secondary Mentor
 
-A person who helps out a student's assigned mentor. At time of writing this guide, the GSoC online system only allows one mentor to be officially assigned to a student proposal, as one person must be responsible for submitting evaluations, etc. However, it is quite common to have multiple mentors for one student.
-
+A person who helps out a GSoC contributor's assigned mentor. At time of writing this guide, the GSoC online system only allows one mentor to be officially assigned to a GSoC contributor proposal, as one person must be responsible for submitting evaluations, etc. However, it is quite common to have multiple mentors for one GSoC contributor.
 
 ## SMOP
 
 Simple Matter of Programming
 
-
 ## Summer
 
-Not so much a season as a state of being. While the program is run during the Northern Hemisphere's Spring and Summer, the "Summer" in Google Summer of Code is actually a play on the "Summer of Love.
-
+Not so much a season as a state of being. While the program is run during the Northern Hemisphere's Spring and Summer, the "Summer" in Google Summer of Code is actually a play on the "Summer" of Love.
 
 ## TDD
 
 Test Driven Development
 
-
 ## Use Case
 
 A use case describes what a user can do with a particular software system. <http://en.wikipedia.org/wiki/Use_case>
 
-
 ## Waterfall Model
 
 A sequential software development process.
-
-
diff --git a/pages/student/00-what_is_google_summer_of_code.md b/pages/student/00-what_is_google_summer_of_code.md
index a2804897..25d46863 100644
--- a/pages/student/00-what_is_google_summer_of_code.md
+++ b/pages/student/00-what_is_google_summer_of_code.md
@@ -6,32 +6,27 @@ permalink: student/index.html
 sidebar: student_sidebar
 ---
 
-You've heard other students talking about it, you've seen flyers and blog posts on it and now you want to know more! So here we go...
+You've heard people talking about it, you've seen flyers and blog posts on it and now you want to know more! So here we go...
 
-Google Summer of Code (GSoC) is a global program that matches students up with open source, free software and technology-related organizations to write code and get paid to do it! The organizations provide mentors who act as guides through the entire process, from learning about the community to contributing code. The idea is to get students involved in and familiar with the open source community and help them to put their summer break to good use.
+Google Summer of Code (GSoC) is a global, online program that brings new contributors into open source software organizations. The program began in 2005 and until 2021 was focused on bringing university students into open source. Starting in 2022, we have expanded the program to welcome students and all beginner contributors to open source who are 18 years and older to apply to the program as GSoC Contributors. These GSoC Contributors will write code and become part of these open source communities while making some money along the way. The organizations provide mentors who act as guides through the entire process, from learning about the community, to helping GSoC Contributors become familiar with the code base and testing practices, to finally releasing their code for the world to use! The ultimate goal is that these GSoC Contributors will become excited about the communities they are involved with during the program and will continue to actively contribute to the communities long after their GSoC program ends - or maybe start their own open source project!
 
-Accepted students gain exposure to real-world software development and employment opportunities in areas related to their academic pursuits. Participating organizations are able to identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all; all code produced as part of the program is released under an open source license. The fact that you get to write code that people from all over the world can use - how cool is that!
-
-This program has brought together thousands of students and mentors from over 118 countries worldwide. As of November 2019, 686 open source projects, from areas as diverse as operating systems and community services, have participated as mentoring organizations for the program. Successful students have widely reported that their participation in GSoC made them more attractive to potential employers and that the program has helped greatly when embarking on their technical careers.
+Accepted GSoC Contributors gain exposure to real-world software development while having their mentor(s) ready to help integrate them into the community and help them become stronger developers. Best of all, more source code is created and released for the use and benefit of all; all code produced as part of the program is released under an open source license. The fact that you get to write code that people from all over the world can use - how cool is that!
 
+Since 2005, GSoC has brought together 38,000 GSoC contributors and mentors from over 146 countries. As of December 2023, over 850 open source projects, from areas as diverse as operating systems and community services, have participated as mentoring organizations for the program. Successful students have widely reported that their participation in GSoC made them more attractive to potential employers and that the program has helped greatly when embarking on their technical careers. Many past students and GSoC Contributors continue to be involved in GSoC by becoming mentors themselves and helping new contributors learn about the exciting things their community is working on and the satisfaction that comes with being a part of a community of dedicated developers in open source.
 
 ## Goals of the Program
 
 The GSoC program has several goals:
 
-*   Get more open source code written and released for the benefit of all.
-*   Inspire young developers to begin participating in open source development.
-*   Help open source projects identify and bring in new developers.
-*   Provide students the opportunity to do work related to their academic pursuits during the summer: "flip bits, not burgers."
-*   Give students more exposure to real-world software development (for example, distributed development and version control, software licensing issues, and mailing list etiquette).
-
+* Inspire developers to begin participating in open source development.
+* Help open source projects identify and bring in new developers.
+* Get more open source code written and released for the benefit of all.
+* Give newer developers more exposure to real-world software development (for example, distributed development and version control, software licensing issues, testing, and communication best practices).
 
 ## A Brief History of Google Summer of Code
 
-Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. In GSoC's first year, 40 projects and 400 students participated. By the conclusion of the 15th Google Summer of Code in 2019, over 16,000 students have been accepted into the program. Best of all, most of the organizations participating over the past 15 years reported that the program helped them find new community members and active committers.
+Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. In GSoC's first year, 40 projects and 400 students participated. By the conclusion of the 18th Google Summer of Code in 2023, over 19,000 GSoC contributors from 116 countries have been accepted into the program. Best of all, most of the organizations participating over the past 18 years reported that the program helped them find new community members and active committers.
 
-GSoC has grown immensely over the last 15 years and in the process helped students make the most of their summer by working on exciting open source projects.
+GSoC has grown immensely over the last 19 years and in the process helped students make the most of their summer by working on exciting open source projects.
 
 You can take a look at the appendix if you're interested in a more extensive history of the program.
-
-
diff --git a/pages/student/01-why_should_i_apply.md b/pages/student/01-why_should_i_apply.md
index 8ada5360..5e46d742 100644
--- a/pages/student/01-why_should_i_apply.md
+++ b/pages/student/01-why_should_i_apply.md
@@ -6,7 +6,7 @@ permalink: student/why-should-i-apply.html
 sidebar: student_sidebar
 ---
 
-So you've found out about this Google Summer of Code thing that requires you to submit a lengthy proposal and write a lot of code. Why bother about it at all? Well, here are some reasons why you should start writing your proposal today!
+So you've found out about this Google Summer of Code thing that requires you to reach out to an organization to talk about their project ideas, then submit a lengthy proposal and write a lot of code. Why bother about it at all? Well, here are some reasons why you should start reaching out to organizations that you are interested in today!
 
 **An absolutely amazing learning experience**
 
@@ -14,11 +14,11 @@ GSoC is a place where you don't just get to apply your skills but also get to ac
 
 "GSoC is one of the best professional experience a student can have during his college years. I've participated twice already, but now I'm starting to regret I didn't do this every year! Awesome! Thank you Google! "
 
-Evelina Vrabie, Sunlight Foundation, GSoc Student 2010
+Evelina Vrabie, Sunlight Foundation, GSoc Student
 
 "This is a big opportunity for all the students like us to use the things that we are learning in colleges in a practical manner. Thanks Google and all the mentoring organization for allocating your valuable time."
 
-Kasun (Lakpriya) Hettige, Apache Software Foundation (ASF), GSoC Student 2010
+Kasun (Lakpriya) Hettige, Apache Software Foundation (ASF), GSoC Student
 
 **Sense of achievement**
 
@@ -26,7 +26,7 @@ There is something very fulfilling about getting your first patch committed upst
 
 "I just want to say...it feels *awesome* when your first patch goes in.  Really awesome. "
 
-Mike Conley, Review Board, GSoC Student 2010
+Mike Conley, Review Board, GSoC Student
 
 **Hone your developer skills**
 
@@ -34,7 +34,7 @@ Students who are already active developers can apply themselves to a specific pr
 
 "At this time one of the most memorable incident happened in my life, where my mentor proposed me as a committer, and my ambition to become an Apache committer finally became true. "
 
-S. Suhothayan, ASF, GSoC Student 2010
+S. Suhothayan, ASF, GSoC Student
 
 **Getting involved and building your network**
 
@@ -42,11 +42,11 @@ During the 12 weeks of writing good code, you interact and share ideas with some
 
 "Exciting and challenging. I met kind, knowledgeable and smart people all gathered in a single place, united, working for a single goal. "
 
-José Luis Vergara Toloza, KDE, GSoC Student 2010
+José Luis Vergara Toloza, KDE, GSoC Student
 
 "Summer of Code is about much more than just code. The sheer fun of integrating with the open-source community and your mentoring organization can in fact outweigh the gratification of actual coding. "
 
-Kamran Khan, Ubuntu, GSoC Student 2010
+Kamran Khan, Ubuntu, GSoC Student
 
 **Your spring-board to the open source world**
 
@@ -54,14 +54,16 @@ GSoC is a great place to get you jump started and up to speed on the basics of t
 
 "GSoC 2010 was my first real foray into the Open Source World -- I had been teetering at just the edge of actual contribution for a few years, having tried out WordPress, etc. but had never actually ever submitted a patch, or released a project. "
 
-Kunal Bhalla, WordPress, GSoC Student 2010
+Kunal Bhalla, WordPress, GSoC Student
 
 **For the love of code**
 
 If you enjoy coding and feel passionate about writing good quality code and building great software, GSoC is THE place for you to give way to your passion. After all, what better way is there to celebrate your love for the code by participating in a summer of code.
 
-**The stipend and the fame**
+**Being mentored by highly experienced developers**
 
-One very tangible and obvious advantage of participating in GSoC is the stipend that you make while working with amazing people on a great project. Being a successful GSoC student is in fact a prestigious achievement. It's another way to make your resume more impressive. 
+GSoC at its heart is a mentorship program. The mentors are dedicated, passionate volunteers who want to help GSoC Contributors learn about their communities and teach them how to be great open source contributors. Having the opportunity to be guided by people who have been doing this for many years and who know the tips and tricks can only help you be a better, more confident open source developer.
 
+**The stipend and the confidence**
 
+One very tangible and obvious advantage of participating in GSoC is the stipend that you make while working with amazing people on a great project. You won't get rich participating in GSoC as a Contributor, but the money can certainly help while you are building your skills and doing meaningful contributions. Being a successful GSoC student is in fact a prestigious achievement. It's another way to make your resume more impressive.
diff --git a/pages/student/02-am_i_good_enough.md b/pages/student/02-am_i_good_enough.md
index be5a71d8..c1dd442c 100644
--- a/pages/student/02-am_i_good_enough.md
+++ b/pages/student/02-am_i_good_enough.md
@@ -6,14 +6,13 @@ permalink: student/am-i-good-enough.html
 sidebar: student_sidebar
 ---
 
-Do you have *some* programming experience at the university level? Then, yes, you are good enough! No, you don't need to be a Computer Science or IT major. Students from all subject areas are successful GSoC students. Have work experience programming but spend your time studying philosophy full-time? Yes, you are good enough to be a GSoC student!
+Do you have *some* programming experience and are comfortable in at least one or two programming languages? Then, yes, you are good enough! No, you don't need to be a Computer Science or IT major or have been coding for 5 years. Have work experience programming but spend your time studying philosophy? Yes, you are good enough to be a GSoC contributor!
 
 "Although at first I was a little inexperienced in the world of mobile applications and a bit overwhelmed by the challenge, I can positively say that four months later I've gradually overcome all the obstacles. I had a great mentor, that's for sure!"
 
-Evelina Vrabie, Romania, Android Project - GSoC 2010
-
-Every project has a different criteria for selecting students and subsequently different skill level requirements. If you meet the below list of general skills you are likely to find a GSoC project to which you can feel comfortable applying:
+Evelina Vrabie, Romania, Android Project - GSoC student
 
+Every project has a different criteria for selecting GSoC contributors and subsequently different skill level requirements. If you meet the below list of general skills you are likely to find a GSoC project to which you can feel comfortable applying:
 
 ## The soft skills
 
@@ -23,7 +22,7 @@ There are many available resources on the interwebs to go to for help with techn
 
 **You take and respond well to feedback**
 
-The community developed software model relies heavily on constructive feedback and the willingness for each contributor to take that criticism and make the code better.   You are going to be getting regular feedback from your mentor -- not all of it is going to be "this is great" "you are awesome." Learning from and graciously accepting feedback is a very important trait for a successful GSoC student.
+The community developed software model relies heavily on constructive feedback and the willingness for each contributor to take that criticism and make the code better. You are going to be getting regular feedback from your mentor -- not all of it is going to be "this is great" "you are awesome." Learning from and graciously accepting feedback is a very important trait for a successful GSoC contributor.
 
 **You can work independently**
 
@@ -33,6 +32,9 @@ Since you'll be spending significant amounts of time working alone - not being a
 
 Do you think you already know everything about everything in the world of open source programming?  Then you probably aren't good enough for GSoC!
 
+**You can communicate effectively**
+
+Communication is key to GSoC. We will mention this many times in this guide. Being a successful GSoC contributor requires you to communicate with your mentor and the community regularly. Much of the time the communication is via chat or email but you may also have weekly video chats with your mentor or community. If you are behind schedule or you are stuck on implementing something but have tried to find the answer to no avail, reach out to the community and your mentor, don't stay stuck.
 
 ## The technical stuff
 
@@ -40,16 +42,18 @@ Do you think you already know everything about everything in the world of open s
 
 If you don't know how to download and install packages on your own, you'll need to figure that out, stat.
 
-**You have access to a functioning computer 30 hours a week**
+**You have access to a functioning computer**
 
-If your computer regularly dies, or you don't have dedicated access to a computer you'll need to figure that out before you start your project. Also, GSoC should be considered a full-time commitment. Don't expect an hour or two a day in an internet cafe to be enough!
+If your computer regularly dies, or you don't have dedicated access to a computer you'll need to figure that out before you start your project. GSoC is a significant time commitment, don't expect an hour or two a day in an internet cafe to be enough!
 
 **You've got experience using the programming language and operating system of the project**
 
-Depending on the project, the skills necessary will range from beginner to expert, but you do need some experience.  One of the great things about GSoC is that there is a large variety of organizations and projects to choose from. Chances are very good that you can find a project that meets you at your level.  Even if you are a beginner! If the project primarily uses Linux for development and distribution, then you need to be comfortable with basic Linux usage. Sometimes, you'll see projects looking to expand onto other platforms, in which case you may be able to bring in new expertise.
+Depending on the project, the skills necessary will range from beginner to expert, but you do need some experience.  One of the great things about GSoC is that there is a large variety of organizations and projects to choose from. Chances are very good that you can find a project that meets you at your level, even if you are a beginner! If the project primarily uses Linux for development and distribution, then you need to be comfortable with basic Linux usage. Sometimes, you'll see projects looking to expand onto other platforms, in which case you may be able to bring in new expertise.
 
-Every project has additional characteristics that they look for when selecting students and projects - however, if you meet the above basic criteria - chances are good that there are GSoC projects and organizations to which you can feel comfortable applying.
+Every project has additional characteristics that they look for when selecting contributors and projects - however, if you meet the above basic criteria - chances are good that there are GSoC projects and organizations to which you can feel comfortable applying.
 
-**Pro Tip:** Don't be afraid to apply to projects where you only meet 51% of the listed requirements.  Include a section on how you'll compensate for or learn the missing skills - and demonstrate during the application process that you are working on acquiring those new skills.
+**Pro Tip: Read the organization's requirements or skills they are looking for in potential GSoC Contributors**
 
+Be aware that some requirements are likely to be firm and you must meet those requirements for the organization to consider your application. For example, many organizations require potential GSoC contributors to submit pull requests as part of their application, or they require you to have a chat with someone in the community about your idea before submitting your proposal. More complicated projects will likely require familiarity with particular programming languages, processes or techniques. It is also possible some organizations may be looking for students who are earlier in their development, while other organizations may be looking for applicants more advanced in their skills.
 
+However, some of the requirements may be less stringent and could be things you can learn quickly, just be sure to mention that you are working on these skills, etc. when you are discussing your proposal with the organization.
diff --git a/pages/student/03-making_first_contact.md b/pages/student/03-making_first_contact.md
index dbe00e3c..1e39a3b6 100644
--- a/pages/student/03-making_first_contact.md
+++ b/pages/student/03-making_first_contact.md
@@ -12,27 +12,23 @@ Interacting with an open source group is sort of like walking in on a party wher
 
 If you're the type of person that would walk right up and introduce yourself at a party, then the best approach to getting started is to do what you'd do in real life. Contact the project, introduce yourself and ask questions related to your project.
 
-However, if you're more likely to hang back and watch people for a while, spend some time observing community interactions before you jump in. You can also try to contact an organization admin for guidance, or with help introducing you to a community. If in doubt, have a look at the organization's ideas page for hints on where to go for help.
-
+However, if you're more likely to hang back and watch people for a while, spend some time observing community interactions before you jump in. Have a look at the organization's ideas page for hints on where to go for help. GSoC Organizations have listed their preferred contact methods for GSoC contributors to use on their program homepage and they are ready to welcome you through these channels.
 
 ## How to observe community interactions
 
-*   Join both the development and user mailing lists and spend a few days just reading the conversations.
-*   Read the mailing list archives.
-*   Join the project's discussion forums/chat channel (IRC, Discourse) and lurk for a bit.
-*   Read all the available information on past GSoC projects.
-*   Take a stab at going through the project documentation, at least to the point where you feel like you can ask questions that are not already extensively covered in the docs.
+* Join both the development and user mailing lists and spend a few days just reading the conversations.
+* Read the mailing list archives.
+* Join the project's discussion forums/chat channel (IRC, Discourse, Slack) and lurk for a bit.
+* Read all the available information on past GSoC projects.
+* Take a stab at going through the project documentation, at least to the point where you feel like you can ask questions that are not already extensively covered in the docs.
 
 At the end of your "listening and research" phase you'll understand how, where and when the community interacts and know the best way to ask questions.
 
-
 ## How to begin participating in conversations
 
-*   Introduce yourself! If you are new to the community you need to let people know who you are and why you are interested in contributing to the project.
-*   Ask questions. You should be able to come up with at least a few legitimate questions before offering your opinion on the right way to do things.
-*   Be humble. Until you've engaged with the community, for at least a few months, assume that those people talking about things probably are privy to community nuances you might not yet see.
-*   Don't be intimidated. Don't let a bad experience stop you from getting involved. Just relax and think about why you were snubbed and if there's anything that you should be careful about before participating in another conversation.
-
-No matter what, don't wait until you apply to initiate contact! Engage with multiple communities once the participating organizations are chosen to get a feel for how different groups work.
-
+* Introduce yourself! If you are new to the community you need to let people know who you are and why you are interested in contributing to the project.
+* Ask questions. You should be able to come up with at least a few legitimate questions before offering your opinion on the right way to do things.
+* Be humble. Until you've engaged with the community, for at least a few months, assume that those people talking about things probably are privy to community nuances you might not yet see.
+* Don't be intimidated. Don't let a bad experience stop you from getting involved. Just relax and think about why you were snubbed and if there's anything that you should be careful about before participating in another conversation.
 
+No matter what, don't wait until the application period to initiate contact - really! Engage with multiple communities once the participating organizations are chosen to get a feel for how different groups work and find the one or two that fit your interests/personality.
diff --git a/pages/student/04-choosing_an_organization.md b/pages/student/04-choosing_an_organization.md
index 4521e21e..baea3a24 100644
--- a/pages/student/04-choosing_an_organization.md
+++ b/pages/student/04-choosing_an_organization.md
@@ -12,22 +12,18 @@ You now have a pretty good sense of what GSoC is all about. You've got the time
 
 Kapila Bogahapitiy, Network Time Protocol Project, GSoc Student 2009, 2010
 
-
 ## Who Am I?
 
 The very first requirement for a successful GSoC experience is finding a project/organization that interests you. Take a few minutes to consider the following questions. You can use the answers to these questions to search and filter through the organizations participating in GSoC.
 
-*   What open source software do you use?
-*   What are your professional interests?
-*   What are your hobbies?
-*   What is your skill set?
-*   What do you want to get out of GSoC?
-
+* What open source software do you use?
+* What are your professional interests?
+* What are your hobbies?
+* What is your skill set?
+* What do you want to get out of GSoC?
 
 ## Who Are They?
 
-After the GSoC program is announced each year, a list of accepted organizations is published on the GSoC website. Compile a list of organizations based on your answers above. The projects are also tagged with categories of programming language, platforms, topics and applications. Use the tags to filter organizations based on your skills and interests.
-
-For each organization, take some time to learn more about what they do (i.e., Google them!). The organization's mission, it's size and range of applications may all influence your interest in working with them. Realize that through GSoC you will be joining an open source community. Ideally, you'll find an organization that you are enthusiastic to be a part of.
-
+After the GSoC program is announced each year, a list of accepted organizations is published on the GSoC website (usually in February). Compile a list of organizations based on your answers above. The projects are also tagged with categories of programming language, platforms, topics and applications. Use the tags to filter organizations based on your skills and interests.
 
+For each organization, take some time to learn more about what they do (i.e., Google them!). The organization's mission, its size and range of applications may all influence your interest in working with them. Realize that through GSoC you will be joining an open source community. Ideally, you'll find an organization that you are enthusiastic to be a part of for many years to come!
diff --git a/pages/student/05-finding_the_right_project.md b/pages/student/05-finding_the_right_project.md
index de6f3a05..2074f1d6 100644
--- a/pages/student/05-finding_the_right_project.md
+++ b/pages/student/05-finding_the_right_project.md
@@ -6,32 +6,26 @@ permalink: student/finding-the-right-project.html
 sidebar: student_sidebar
 ---
 
-Each organization will have a project Ideas Page linked to from the official Google list of accepted organizations. Browse the list of project ideas for each of the organizations for which you are interested. The ideas should give you a clear sense of the range and depth of projects being targeted and the expectations in terms of prior experience and programming skills. In addition to the list of project ideas, many organizations encourage original ideas proposed by students.
-
+Each organization will have a Project Ideas Page linked to from the official Google list of accepted organizations. Browse the list of project ideas for each of the organizations for which you are interested. The ideas should give you a clear sense of the range and depth of projects being targeted and the expectations in terms of prior experience and programming skills. In addition to the list of project ideas, many organizations encourage original ideas proposed by potential GSoC contributors.
 
 ## Shortlist
 
 There's a big sea of projects out there for GSoC. Start by compiling a list of potential project ideas that catch your interest. For each idea, take some time to carefully consider what is being proposed, how its scope might be better defined, and how it might fit in with the larger picture.
 
-
 ## Ask questions
 
 Consider any questions you might have about the project, how it might be implemented, and what it would entail. Read the FAQs. If there's still anything unclear about the project and requirements, get your doubts cleared. Formulate your questions and suggestions regarding each idea into a clear and concise communication.
 
-
 ## Evaluate your options
 
 Once you've researched the shortlisted projects and got your questions answered, re-evaluate your options before writing the proposal. Also think about whether the communities you're interested in match your needs, and if you'll have fun working with those people. Is there enough documentation and help available to get you started on the project? Given all the feedback, do you think you're really excited about the project and think that you can do a good job of it?
 
-
 ## From Project Idea to Project Plan
 
 You've narrowed down your search of organizations and projects, you've made first contact, and you've started communicating directly with potential mentors. Now it's time for the critical process of turning a project idea into a project plan.
 
-In most cases, your potential mentor(s) will have lots of ideas and preconceptions about each project that were not included in its original description on the Project Ideas page. Discuss and research the project idea in as much detail as possible. You may even consider preparing mock-ups (illustrations, powerpoint, or websites) to help clarify your understanding and vision of the project. You will want to discuss the scope of the project idea, including which parts are critical versus optional for the summer timeline. This process will directly feed into your application and ideally distinguish it from all the others. Just think about it: if you've helped clarify the project idea and contributed to an actual plan of action, it makes it an easy process for mentors to evaluate your proposal and give it a high ranking!
+In most cases, your potential mentor(s) will have lots of ideas and preconceptions about each project that were not included in its original description on the Project Ideas page. Discuss and research the project idea in as much detail as possible. You may even consider preparing mock-ups (illustrations, powerpoint, or websites) to help clarify your understanding and vision of the project. You will want to discuss the scope of the project idea, including which parts are critical versus optional for the program timeline. This process will directly feed into your application and ideally distinguish it from all the others. Just think about it: if you've helped clarify the project idea and contributed to an actual plan of action, it makes it an easy process for mentors to evaluate your proposal and give it a high ranking!
 
 **Pro Tip:** The earlier you apply, the better. Submitting your proposal early helps you get early feedback.
 
 **Don't be that person**: Cut and pasting an idea from the organization page and turning that in as your project's description is a big no-no. You'll be expected to research and submit your own ideas about how to accomplish the project your way, not just state the end result.
-
-
diff --git a/pages/student/06-writing_a_proposal.md b/pages/student/06-writing_a_proposal.md
index cc89400d..77b29263 100644
--- a/pages/student/06-writing_a_proposal.md
+++ b/pages/student/06-writing_a_proposal.md
@@ -6,19 +6,17 @@ permalink: student/writing-a-proposal.html
 sidebar: student_sidebar
 ---
 
-This is a competitive program, each year Google turns down many more students than it funds. While pre-proposal activities are key to improving your chances of success, a poorly-written proposal is an easy way to fail. There is much you can do to ensure that your project proposal catches the attention of organization reviewers *in a positive way.*
-
+This is a competitive program, each year Google turns down many more applicants than it funds. While pre-proposal activities are key to improving your chances of success, a poorly-written proposal is an easy way to fail. There is much you can do to ensure that your project proposal catches the attention of organization reviewers _in a positive way._
 
 ## The Basics
 
-First and foremost, make sure you meet Google's formal requirements for participation in Summer of Code. Hopefully, you have already checked this by now, but be sure to double-check before you waste time and energy on a proposal.
-
-Inventory your time. Figure out how many hours per week are already spoken for outside of your GSoC commitment, including time spent volunteering for other projects and activities, and counting credit-hours of University instruction. GSoC should be treated as a full-time job.  If you have more than a few hours a week of extra commitments, you probably should skip GSoC; it is unlikely that you will be successful. In any case, be completely clear about outside time commitments as part of your proposal. Do not surprise an organization with your time commitments later on.
+First and foremost, make sure you meet [Google's formal requirements](https://summerofcode.withgoogle.com/rules#:~:text=for%20the%20duration%20of%20the%20Program%2C%20be%20eligible%20to%20work%20in%20the%20country%20in%20which%20they%20reside%3B%20and) for participation in Summer of Code. This includes ensuring that you are **eligible to work** in the country where you reside for the duration of the program. Remember, if you are in a country on a student visa or another type of visa you could have restrictions on the number of hours you can participate in a program like GSoC or you may not be eligible to participate at all. Hopefully, you have already checked this by now, but be sure to double-check before you waste time and energy on a proposal.
 
-Make sure that you are able to be in regular close contact with organization mentors via the usual open source means (email, chat, etc) for the duration of the Summer. It is not necessary that you be geographically near your mentor. However, if you are not sure you will have good Internet connectivity continuously over the summer, GSoC is not for you.
+Inventory your time. Figure out how many hours per week are already spoken for outside of your GSoC commitment, including time spent volunteering for other projects and activities, a part-time job or counting credit-hours of academic instruction. In any case, be completely clear about outside time commitments as part of your proposal. If you know you need to take a couple of weeks off because of finals or a wedding, etc. be upfront with the mentors, we have added some flexibility into the program so this should be fine, you just need to let your mentor know as soon as you know the details. Do not surprise an organization with your time commitments later on. It may be possible to extend the end date of your project if your org will allow it. But this should be discussed early on so everyone can be on the same page.
 
-This program is the Google Summer of *Code.*  If you are less than fluent in the programming languages that your target organization uses, you might want to skip the work of writing an application. If you do decide to proceed, be clear about your level of ability, so that the organization can make an informed decision.
+Make sure that you are able to be in regular close contact with organization mentors via the usual open source means (email, chat, etc) for the duration of the program. It is not necessary (or likely possible) that you be geographically near your mentor. However, if you are not sure you will have good Internet connectivity continuously over the summer, GSoC is not for you.
 
+This program is the Google Summer of _Code._ If you are less than fluent in the programming languages that your target organization uses, you might want to skip the work of writing an application. If you do decide to proceed, be clear about your level of ability, so that the organization can make an informed decision.
 
 ## Elements of a Quality Proposal
 
@@ -28,11 +26,11 @@ There are certain elements of the proposal that should apply to every organizati
 
 **Name and Contact Information**
 
-Putting your full name on the proposal is not enough. Provide full contact information, including email addresses, websites, IRC nick, postal address and telephone number. 
+Putting your full name on the proposal is not enough. Provide full contact information, including your preferred name, email address, websites, etc.
 
 **Title**
 
-Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your synopsis.
+Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your synopsis. Do not put your name in the title.
 
 **Synopsis**
 
@@ -40,7 +38,7 @@ If the format allows, start your proposal with a short summary, designed to conv
 
 **Benefits to Community**
 
-Don't forget to make your case for a benefit to the organization, not just to yourself.  Why would Google and your organization be proud to sponsor this work? How would open source or society as a whole benefit? What cool things would be demonstrated?
+Don't forget to make your case for a benefit to the organization, not just to yourself. Why would Google and your organization be proud to sponsor this work? How would open source or society as a whole benefit? What cool things would be demonstrated?
 
 **Deliverables**
 
@@ -56,48 +54,45 @@ Keep your personal info brief. Be sure to communicate personal experiences and s
 
 **Follow the Rules**
 
-Most organizations accept only plain text applications. Most organizations have a required application format. Many organizations have application length limits. In general, organizations *will* throw out your proposal if you fail to conform to these guidelines. If you feel you *must* have graphical or interactive content associated with your application, put just this content (not a copy of your proposal) on the web and provide an easy-to-type URL. Do not expect reviewers to follow this link.
-
-
-## Submit a Draft Proposal early
-
-Submit your draft proposal early during the application period so that the organization mentors can review it and ask you questions or request more detail on aspects of your proposal before the final deadline.
+You will need to generate a PDF version of your proposal to upload.
 
-Remember, thousands of students are submitting proposals so it can take organizations a few days or even a week+ to get back to you if they have questions. So the earlier you submit a well written draft proposal, the more time they have to give you feedback on it so you can make it stronger and understand more of what they are looking for.
+Many organizations have a required application format or other guidlines including application length limits.
+In general, organizations _will_ throw out your proposal if you fail to conform to any guidelines they specify.
 
-Follow the instructions from the organizations on the content and format of your proposal and use the GSoC program site instructions on successfully submitting and sharing a draft to the organization. You must create the draft and write an abstract before sharing the draft with the organization.
+You should take the time to polish your proposal.  Make it look professional, and be sure to have detailed information
+about your plans.
 
-You can edit the draft as many times as you wish before the application deadline.
+## Submit a Proposal early
 
+Submit your proposal early during the application period so that the organization mentors can review it and ask you questions or request more detail on aspects of your proposal before the final deadline. You can edit the proposal as many times as you wish before the application deadline. You may even want to label the proposal as a draft so it is clear you are looking for feedback before submitting the final proposal.
 
-## Submitting a Final PDF Proposal
+Remember, thousands of potential GSoC contributors are submitting proposals so it can take organizations a few days or even a week+ to get back to you if they have questions. So the earlier you submit a well written draft proposal, the more time they have to give you feedback on it so you can make it stronger and understand more of what they are looking for.
 
-**Before the application period closes you must submit a Final PDF Proposal** - this must be done for your proposal to be considered for the GSoC program. If you only submit a draft and fail to submit the Final PDF Proposal the organizations will not be able to see your proposal and therefore will not be able to accept you - it is an automatic reject from the system.
-
-Follow the instructions on the GSoC site and the process is quite straightforward.
+Follow the instructions from the organizations on the content and format of your proposal.
 
+Remember to submit your final draft before Google's deadline, regardless of if you have received any feedback or not from the org. If you do not have a proposal submitted in the GSoC webapp by the deadline there will be nothing for the org to look at. There are absolutely no extensions to deadlines in GSoC proposal submissions for anyone, ever.
 
 ## Outside the Project List
 
-Some organizations allow students to propose work that is not on their official Ideas Page. This can be a great opportunity to get your proposal on the top of the stack. Reviewers tend to get excited about a student that goes beyond a direct response and enthusiastically proposes work that is novel and creative.
+Some organizations allow GSoC contributors to propose work that is not on their official Ideas Page. This can be a great opportunity to get your proposal on the top of the stack. Reviewers tend to get excited about a GSoC contributor that goes beyond a direct response and enthusiastically proposes work that is novel and creative.
 
 However, original proposals are also riskier; their flaws will be much more apparent. Here's some of the ways that such proposals fail:
 
 **Projects without a mentor**
 
-Try to make sure that someone in the organization would be competent to work with you.
+Try to make sure that someone in the organization would be willing and competent to work with you.
 
 **Projects that better belong with other Summer of Code organizations**
 
-Open source organizations try hard to avoid stepping on each other's turf. Try to find your best customer.
+Open source organizations try hard to avoid stepping on each other's turf. Try to find your best fit.
 
 **Projects that represent too large a scope**
 
-The time flies by quickly. If you have a large project, break it into small, coherent pieces and propose to get the first couple of them done. That way the organization can be confident that they will get at least one good piece of work out of you.
+The time flies by quickly. If you have a large project, break it into small, coherent pieces and propose to get the first couple of them done. That way the organization can be confident that you can complete a project in the allotted time and the project isn't left incomplete indefinitely.
 
 **Incoherent proposals**
 
-The organization needs to see a clearly delimited, contained piece of work. If the organization can't understand or define the work, the proposal will be thrown out.
+The organization needs to see a clearly contained piece of work. If the organization can't understand or define the work, the proposal will be thrown out.
 
 **Projects that are "inappropriate" for legal or social reasons**
 
@@ -105,7 +100,7 @@ If your proposal is near the boundary, make sure you clear it with your target o
 
 **Boring projects**
 
-For the mentor and the organization, half the fun is helping a student do something novel and cool. Infrastructure *per se* isn't necessarily boring, but it should be part of a luminous vision.
+For the mentor and the organization, half the fun is helping a GSoC contributor do something novel and cool. Infrastructure _per se_ isn't necessarily boring, but it should be part of a luminous vision.
 
 **Stuff that's already been done to death**
 
@@ -113,7 +108,6 @@ Novel work should be novel. Surprise.
 
 Even given this list, there's plenty of room for cool work. Given the opportunity, you should seriously consider taking advantage and writing a proposal that differentiates you.
 
-
 ## General Notes
 
 While there is an official limit of three submitted proposals, it is okay to submit more than one high-quality proposal. If you have several strong possibilities for the same organization, consider submitting several proposals. Organizations will figure out which one they like best. But avoid sending many medium-quality proposals and concentrate on fewer high-quality proposals.
@@ -122,6 +116,4 @@ Most organizations are risk averse. It is better for everyone if your project is
 
 Integrate and leverage existing open source code in your project. Only propose to write something yourself if you cannot get it any other way.
 
-The "Pencils Down" deadline for your project to be complete is usually sometime in mid-August. This will come sooner than you think.
-
-
+The "Pencils Down" deadline for your project to be completed will come sooner than you think.
diff --git a/pages/student/07-being_turned_down.md b/pages/student/07-being_turned_down.md
index a06f7052..cf87b313 100644
--- a/pages/student/07-being_turned_down.md
+++ b/pages/student/07-being_turned_down.md
@@ -10,7 +10,6 @@ You've done your homework, found an exciting project, and you've written the bes
 
 Don't despair! The beauty of engaging in the GSoC process is that you're learning about groups of people that extend beyond just GSoC. Making contact with potential mentors and a software community sets the stage for future opportunities for participating in community-developed open source software projects.
 
-
 ## What to do now?
 
 First, don't take it personally. Just like when you apply for a job, there are reasons why you might not get in, some that have nothing to do with you. Mentors may not be available, the organization may not have enough space for your project or it may just not be the right time for your proposal.
@@ -21,28 +20,30 @@ So, where to go from here? There are several strategies you can consider to go f
 
 Just like in job interviews, gathering information about why your proposal wasn't accepted is a great thing to do to improve your next application. Some example questions to politely ask if your proposal is turned down include:
 
-*   Was there a mismatch with my skills and the project requirements? If so, what skill areas can I work on to be better qualified next year?
-*   Did I engage enough with the community during the application process?
-*   Do you have any suggestions on how to improve my pre-application communication?
-*   Was my project plan clear?  Do you have any suggestions on how I can better communicate my ideas via the project plan next year?
+* Was there a mismatch with my skills and the project requirements? If so, what skill areas can I work on to be better qualified next year?
+* Did I engage enough with the community during the application process?
+* Do you have any suggestions on how to improve my pre-application communication?
+* Was my project plan clear?  Do you have any suggestions on how I can better communicate my ideas via the project plan next year?
 
 Following up and getting more information about what you might be able to do differently next time is a great pathway to success.
 
+Keep in mind some organizations receive over 100 proposals so they may not be able to give direct feedback to you but it is okay to politely ask for it - even short feedback can be helpful.
+
 **Approach an organization about doing the project anyway**
 
-For those students with the drive to forge ahead without GSoC financial support, you may find that a community really is interested in your project anyway. Don't be afraid to approach your community, GSoC org admin or mentors you communicated with about future contribution.
+For those GSoC contributors with the drive to forge ahead without GSoC financial support, you may find that a community really is interested in your project anyway. Don't be afraid to approach your community, GSoC org admin or mentors you communicated with about future contribution.
 
 Perhaps you can work on a smaller portion of your idea over a longer period of time on your own, or find another project better suited.
 
-Some successful students have even found business sponsorship of their work later on.
+Some successful GSoC contributors have even found business sponsorship of their work later on.
 
 "This story is about how after about one year and half I became a Linux Kernel Maintainer [of] the Bluetooth Subsystem. On the 2009's GSoC, I worked in important new feature in the kernel side of the Bluetooth stack. The work was too big and I wasn't able to finish it, then after some months a big company hired the company I worked with to have me finish that work. [Now] all work is merged in the Linux tree."
 
-Gustavo Padovan, BlueZ, GSoC Student 2009, 2010
+Gustavo Padovan, BlueZ, GSoC Student
 
 **Stay connected**
 
-If you've already invested time and energy getting to know a community, stay involved! Subscribe to relevant mailing lists, participate in IRC or fix small bugs that you have time for.
+If you've already invested time and energy getting to know a community, stay involved! Subscribe to relevant mailing lists, participate in chat channels, or fix small bugs that you have time for.
 
 There are also many non-code ways you can contribute to software. If you're interested in documentation, graphic design, release testing, public relations or marketing, most projects welcome contributions in these areas. Taking on small non-code projects can be a great way to stay connected and build a reputation in a community.
 
@@ -52,7 +53,7 @@ Maybe that project wasn't the right fit! Part of selecting a project is selectin
 
 "I had a look and approached many organizations, and finally decided to hook up with Sakai Foundation. The mentors and the people I interacted with from the community really encouraged me and I felt very comfortable with their coding practices [and] the programming languages."
 
-Ashish Mittal, Sakai Foundation, GSoC Student 2010
+Ashish Mittal, Sakai Foundation, GSoC Student
 
 **Keep trying**
 
@@ -60,6 +61,4 @@ Just keep trying. The next proposal just might be accepted...
 
 "*Never* give up. It took me 3 years and 12 proposals to finally get into the program. If none of your proposals gets accepted, sit back and relax. You have a whole year ahead to improve your role with the open-source community by writing more code."
 
-Kamran Khan, Ubuntu, GSoC Student 2010
-
-
+Kamran Khan, Ubuntu, GSoC Student
diff --git a/pages/student/08-how_gsoc_works.md b/pages/student/08-how_gsoc_works.md
index 427e8c59..6d220b32 100644
--- a/pages/student/08-how_gsoc_works.md
+++ b/pages/student/08-how_gsoc_works.md
@@ -6,46 +6,42 @@ permalink: student/how-gsoc-works.html
 sidebar: student_sidebar
 ---
 
-Google Summer of Code moves in phases after you are accepted. The first phase is the Community Bonding Period in which you get to know your community and get familiar with their code base and work style. The next phase is the initial phase of coding (Phase 1) which is evaluated with Phase 1 evaluation a month into the Google Summer of Code term. The second phase (Phase 2) is evaluated two months into the program coding period. The final phase is your time to complete your project. There will be a final evaluation at the end of the term; you will also need to submit a URL to your work product.
+Google Summer of Code moves in phases after you are accepted. The first phase is the Community Bonding Period (~3 weeks) in which you get to know your community and get familiar with their code base and work style. The next phase is the initial phase of coding (Phase 1) which is evaluated with a midterm evaluation from your mentor halfway through the Google Summer of Code term. The final phase is your time to complete your project (the final half of the program). There will be a final evaluation at the end of the term; you will also need to submit a URL to your work product.
 
 **Evaluations**
 
-Evaluations are not as daunting as they may sound. This is an opportunity for you to evaluate your mentor and your mentor to evaluate you, not a quiz on your coding abilities. Some mentors even choose to review their evaluations afterward with the student in order to integrate the feedback into the coding process for the rest of the term. Be honest about your experiences with the program. This helps GSoC improve in future years. Remember, you must complete your evaluation of your mentor at each phase or you will receive an automatic fail.
+Evaluations are not as daunting as they may sound. This is an opportunity for you to evaluate your mentor and your mentor to evaluate you, not a quiz on your coding abilities. Some mentors even choose to review their evaluations afterward with the GSoC contributor in order to integrate the feedback into the coding process for the rest of the term. Be honest about your experiences with the program. This helps GSoC improve in future years. Remember, you must complete your evaluation of your mentor at the final phase or you will receive an automatic fail.
 
 **Payments**
 
-Payment is in three pieces. The first payment is sent shortly after you pass the Phase 1 evaluation. The second payment is sent after you have passed the Phase 2 evaluation; the final payment is sent once you pass your final evaluation. All of these payments take a few business days to become active on your card or in your bank account if you choose direct deposit.
+Payment is in two pieces. The first payment is sent shortly after you pass the midterm evaluation. The final payment is sent once you pass your final evaluation. Both of these payments can take a few business days to become active in your Payoneer account (which can be linked to your bank account).
 
 **Certificate of Completion**
 
-You may receive a digital certificate of completion at the end of the program if you successfully pass GSoC. 
-
-The rest of your experience with the program will be determined by your interactions with the community within your mentoring organization. Most students consider the interactions with their mentor and the rest of the open source community they're involved with to be the most important part of the Google Summer of Code experience.
+You may receive a digital certificate of completion at the end of the program, available from your GSoC profile on the webapp if you successfully pass GSoC.
 
+The rest of your experience with the program will be determined by your interactions with the community within your mentoring organization. Most GSoC contributors consider the interactions with their mentor and the rest of the open source community they're involved with to be the most important part of the Google Summer of Code experience.
 
 ## Participant Roles
 
 There are four roles in the Google Summer of Code program:
 
-**Student**
+**GSoC contributor**
 
-This is you! A student participant in GSoC is typically a college or university student; the only academic requirement is that the accepted applicants be enrolled in an accredited academic institution. Students must be at least 18 years of age to participate. Students come from a variety of academic backgrounds, and though most students are enrolled in a Computer Science program there is no requirement that they be studying CS. Past students have come from disciplines as varied as Ecology, Medicine, and Music.
+This is you! A GSoC contributor is a student or a new contributor to open source. This person could be a university student, a recent graduate, a person switching careers, a developer early in their career, person returning to the workforce, etc. GSoC Contributors come from a variety of academic backgrounds - many are university students or graduates of coding schools or programs, while others are self-taught.
 
 **Organization Administrator**
 
-Org admins are the "cat herders" for GSoC open source projects. Some org admins also mentor students during GSoC. Org admins are the final authority about matters such as which student projects will be accepted and who will mentor whom. If you're having difficulties communicating with your mentor or making progress, an org admin can help.
+Org admins are the "cat herders" for GSoC open source projects. Some org admins also mentor GSoC contributors during GSoC. Org admins are the final authority about matters such as which GSoC contributor projects will be accepted and who will mentor whom. They are also responsible for approving and adjusting any project deadlines requested by the mentor and GSoC contributor. If you're having difficulties communicating with your mentor or making progress, an org admin can help.
 
 **Mentor**
 
-Mentors are people from the community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, setting milestones for the student, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student contributors integrate into their project's community.
+Mentors are people from the community who volunteer to work with a GSoC contributor. Mentors provide guidance such as pointers to useful documentation, code reviews, setting milestones for the GSoC contributor, etc. In addition to providing GSoC contributors with feedback and pointers, a mentor acts as an ambassador to help GSoC contributors integrate into their project's community.
 
 **Program Administrator**
 
-Program administrators are employees of Google's Open Source Programs Office who run the program. These folks do a variety of tasks: select the participating open source projects each year, create and analyze the program evaluations, administer the program mailing lists, ensure that participants are paid, respond to inquiries about the program. Program administrators do not select which student proposals are accepted into Google Summer of Code.
-
+Program administrators are employees of Google's Open Source Programs Office who run the program. These folks do a variety of tasks: select the participating open source projects each year, create and analyze the program evaluations, administer the program mailing lists, ensure that participants are paid, respond to inquiries about the program. Program administrators do not select which GSoC contributor proposals are accepted into Google Summer of Code.
 
 ## Afterward
 
-It is a primary goal of Google Summer of Code that the student participants stick around long after the program has ended and continue contributing to their project communities. Great mentors continue working with their students and encourage them to do so. In the end, mentors and students take a well-deserved break before the GSoC cycle starts again.
-
-
+It is a primary goal of Google Summer of Code that the GSoC contributors stick around long after the program has ended and continue contributing to their project communities. Great mentors continue working with their GSoC contributors and encourage them to stay actively involved and may help them find a new, fun project to tackle in their community. In the end, mentors and GSoC contributors take a well-deserved break before the GSoC cycle starts again.
diff --git a/pages/student/09-what_does_community_mean.md b/pages/student/09-what_does_community_mean.md
index 63d27744..d45914d7 100644
--- a/pages/student/09-what_does_community_mean.md
+++ b/pages/student/09-what_does_community_mean.md
@@ -8,13 +8,12 @@ sidebar: student_sidebar
 
 The word "community" gets thrown around a lot in open source. So what does it mean?
 
-People involved with open source community have differing political, social, economic and ethnic backgrounds. They range from elementary school students to the elderly. They work across timezones, languages, and cultures.
+People involved with open source community have differing political, social, economic and ethnic backgrounds. They range from elementary school students to the older adults. They work across timezones, languages, and cultures.
 
-Some developers may work on only a small part of the project codebase, while others know every line from memory. Communities also include people who don't work on the source code directly, such as graphic designers or testers.
+Some developers may work on only a small part of the project codebase, while others know every line from memory. Communities also include people who may not work on the source code directly, such as graphic designers, testers, tech writers and community managers.
 
 When talking about community, it helps to focus in on political and social structure. The project participants you talk to may or may not formally represent the project. Assume, unless otherwise stated, that people represent and speak only for themselves when you interact with them. However, identifying the leaders and the project structure can help you to better interact with all members of the project team.
 
-
 ## Community leadership structure
 
 Much of the authority in a project rests with those people who control the community code. At least, it starts there. Actual organization varies widely, but there are some common structures that may help you find your bearings.
@@ -25,7 +24,7 @@ Many projects start with a single developer. As time goes on, this person, often
 
 **Many committers, rough consensus**
 
-Some projects allow almost anyone to change their codebase. These groups are likely to give commit access to GSoC students as part of a project. When deciding which features to work on or what code is committed to the master code repo, decisions may be made by the group or left to a few trusted individuals. When there's conflict, majority approval may be requested before further action is taken.
+Some projects allow almost anyone to change their codebase. These groups are likely to give commit access to GSoC contributors as part of a project. When deciding which features to work on or what code is committed to the main code repo, decisions may be made by the group or left to a few trusted individuals. When there's conflict, majority approval may be requested before further action is taken.
 
 Decisions are often made based on who has working code, rather than on a theoretical basis. Groups may not formally document how they make decisions. In this case, a little time spent with the group can help you learn the culture and how to work together. If you end up working with a group like this, your mentor will help you acclimate!
 
@@ -33,19 +32,16 @@ Decisions are often made based on who has working code, rather than on a theoret
 
 As groups grow in size, some kind of organization becomes necessary. The type of formal organization varies widely across social, cultural and political boundaries.  Some ways of organizing include:
 
-*   Electing a steering committee by a vote of developers.
-*   Forming a non-profit organization or foundation.
-*   Creating a for-profit business.
-*   Joining an existing non-profit organization.
-*   Formalizing the existing developer relationships by naming a group of committers the "core" decision makers.
+* Electing a steering committee by a vote of developers.
+* Forming a non-profit organization or foundation.
+* Creating a for-profit business.
+* Joining an existing non-profit organization.
+* Formalizing the existing developer relationships by naming a group of committers the "core" decision makers.
 
 These groups can have documented processes for assuming leadership roles, and may put more effort into non-code activity. Generally speaking, formal organizations have governing documents, and a clearly documented leadership group that changes from time to time.
 
-
 ## Community is people
 
 Apart from project leaders, open source projects tend to be full of independent, capable people who like to learn. Long-term collaboration tends to turn strangers into friends. Part of what people enjoy about open source development is that they have the opportunity to choose their colleagues. Developers often participate for fun, relaxation and friendship.
 
 When you're talking to a software community, realize that you're really just talking to people, albeit some of the most interesting people who create software. Enjoy the experience and be a good neighbor, and you'll almost always fit right in.
-
-
diff --git a/pages/student/10-open_source_culture.md b/pages/student/10-open_source_culture.md
index 5335f8e3..73bf12a1 100644
--- a/pages/student/10-open_source_culture.md
+++ b/pages/student/10-open_source_culture.md
@@ -6,8 +6,7 @@ permalink: student/open-source-culture.html
 sidebar: student_sidebar
 ---
 
-When you encounter an open source group for the first time, it may be a bewildering experience. Whether posting to a mailing list for the first time, blogging about the project you're taking on or hanging out on an IRC channel - the way people interact, and what they expect from each other is pretty different than in classroom or with friends and family.
-
+When you encounter an open source group for the first time, it may be a bewildering experience. Whether posting to a mailing list for the first time, blogging about the project you're taking on or hanging out on a chat channel - the way people interact, and what they expect from each other is pretty different than in classroom or with friends and family.
 
 ## Openness and Sharing
 
@@ -23,7 +22,6 @@ Although "open culture" is generally informal, it is important to remember that
 
 Most open source communities have their own Code of Conduct (formally or informally). Be sure you are aware of the Code of Conduct and are treating everyone with respect.
 
-
 ## Remote Communication
 
 Many projects involve individuals who are working not only in different cities, countries and continents, but collaborating across major cultural and language differences. And rather than having procedures or policies on how to interact with one another handed down from HR departments or other authorities, communication practices evolve between individuals over time.
@@ -34,37 +32,33 @@ Be mindful of cultural assumptions about race, gender, sexual orientation and di
 
 All that tolerant rhetoric aside, it is never productive for an open source project to allow individuals who consistently try to cause harm to others to do so. If you are causing undue problems don't be surprised if you are asked to discontinue your participation regardless of your contributions. It's often better for an open source project to ask someone to leave, than to allow them to harm others and in turn, cause other productive members of your team to depart.
 
-
 ## Abbreviations and Slang
 
 People come up with abbreviations and slang that are meaningful inside the group, but not necessarily to outsiders. Ask questions when you don't understand a term, a joke or some arcane bit of project lore.
 
 Here are a few useful resources for teasing out meaning from initialisms, acronyms and abbreviations:
 
-*   Urban Dictionary (<http://www.urbandictionary.com>)
-*   Webster's Online Dictionary (<http://www.websters-online-dictionary.org/>)
-*   The Jargon File (<http://www.catb.org/jargon/html/>)
-*   Acronym Finder (<http://www.acronymfinder.com/>)
-*   A to Z word finder (<http://www.a2zwordfinder.com/>)
-
+* Urban Dictionary (<http://www.urbandictionary.com>)
+* Webster's Online Dictionary (<http://www.websters-online-dictionary.org/>)
+* The Jargon File (<http://www.catb.org/jargon/html/>)
+* Acronym Finder (<http://www.acronymfinder.com/>)
+* A to Z word finder (<http://www.a2zwordfinder.com/>)
 
 ## Volunteerism and Gift Economies
 
-Donated time are the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple "thank you" in return.
+Donated time is the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple "thank you" in return.
 
 Contributions to projects are often self-directed, with developers having a personal itch to scratch in the form of a new feature, by correcting a bug that they've encountered or by implementing something from a TODO list. Projects operating in this way may seem chaotic if you are only familiar with top-down management - where teachers, professors or bosses tell you what to do and when. Of course, some projects do have clearly defined project management, with milestones and tasks meted out carefully.
 
-Because many (or in some cases all) contributors are volunteering, methods of coercion available to businesses are not available. The best way to collaborate is to behave in a way that encourages others, and ultimately, makes people want to contribute. Some easy ways to encourage volunteerism include:
+Because many (or in some cases all) community members are volunteering, methods of coercion available to businesses are not available. The best way to collaborate is to behave in a way that encourages others, and ultimately, makes people want to contribute. Some easy ways to encourage volunteerism include:
 
-*   Saying thank you
-*   Giving compliments when they are deserved, regularly and in public
-*   Publicizing cool hacks and features as they are implemented, in blog posts and on the mailing lists
-*   Promptly committing useful code
-*   Responding promptly to requests for information
-*   Clearly defining ways to contribute to your project (TODO lists are great!)
+* Saying thank you
+* Giving compliments when they are deserved, regularly and in public
+* Publicizing cool hacks and features as they are implemented, in blog posts and on the mailing lists
+* Promptly committing useful code
+* Responding promptly to requests for information
+* Clearly defining ways to contribute to your project (TODO lists are great!)
 
 Consider treating every patch like it is a gift. Being grateful is good for both the giver and the receiver, and invigorates the cycle of virtuous giving.
 
 Overall, your goal is to help create and maintain an atmosphere around contribution that is enjoyable. What that means will vary significantly depending on the project, but certainly the above points apply to any project.
-
-
diff --git a/pages/student/11-communication_best_practices.md b/pages/student/11-communication_best_practices.md
index 333f1ff3..75d73325 100644
--- a/pages/student/11-communication_best_practices.md
+++ b/pages/student/11-communication_best_practices.md
@@ -8,11 +8,20 @@ sidebar: student_sidebar
 
 One of the best things about GSoC is the group of individuals from diverse cultures and different open source organizations that participate each year. This also means that you cannot make any assumptions about communication. Specifically:
 
-*   Always read the [Program Rules](https://developers.google.com/open-source/gsoc/rules), [FAQ](https://developers.google.com/open-source/gsoc/faq) and this manual first! One of the best ways to destroy your reputation early is to repeatedly ask questions on IRC or the mailing list that are covered in a FAQ or other types of documentation.
-*   Don't expect instant answers. Remember you are working with volunteers.
-*   Avoid humor when communicating with the entire GSoC community. It does not translate well to large groups and is likely to be misconstrued by someone.
-*   Remember that other peoples' time is just as valuable as your own.
+Issues we see interested contributors do that will irritate your mentors and community very quickly (and likely result in you not being accepted into the org):
 
+* Never address a person with a gendered title (Sir, Mam, etc. unless the person has indicated that a certain title is acceptable). The best thing to do is just say 'Mentors', especially during the application period of the program when you may not know mentor's specific displaynames yet.
+* Never assume a person's gender based on display name, profile pic, etc.
+* Never reach out to mentors during the application period via social media like LinkedIn, etc. to get them to answer your questions if they haven't responded in a couple of days.
+* Don't expect instant answers. Remember you are working with volunteers.
+* One of the best ways to destroy your reputation early is to repeatedly ask questions on the chat channel or the mailing list that are covered in a FAQ or other types of documentation.
+
+Remember...
+
+* Respect the mentors, org admin, other GSoC applicants and the org's community members. Respect everyone equally regardless of their gender.
+* Always read the [Program Rules](https://developers.google.com/open-source/gsoc/rules), [FAQ](https://developers.google.com/open-source/gsoc/faq) and this guide first!
+* Avoid humor when communicating with the entire GSoC community. It does not translate well to large groups and is likely to be misconstrued by someone.
+* Remember that other peoples' time is just as valuable as your own.
 
 ## How to Use a Mailing List
 
@@ -20,27 +29,25 @@ Every community uses mailing lists differently. It is extremely important that y
 
 Some specific guidelines that should apply across communities:
 
-*   Follow the mailing list posting style. Do people top or bottom post? Follow the norm.
-*   Keep your posts on-topic. Avoid tangents and posting "I know this is off-topic but..." type posts. If you have any doubt, email the moderator *before* you post.
-*   Don't cross-post to multiple lists. Communicating well on mailing lists means knowing where and when to post items, if you have any doubts regarding what is appropriate, ask the moderator.
-*   Never send community members unsolicited personal messages. Especially, if your content is along the lines of "the way you talk about code really turns me on." Inappropriate!
-*   If you are offended by a response or post, walk-away. Do not respond when you are angry.
-*   Avoid posting to the mailing list if you are significantly under the influence of anything that makes you behave out of your norm. Just like drunk-dialing is bad -- so is drunk emailing to your open source community mailing list.
-*   Avoid profanity.
-*   Don't post chain letters, marketing messages or other types of non-topical spam.
-*   Always check the archives before re-posting your message. Lots of mail clients don't send you duplicates of your mailing lists posts. Check the archives before you re-send!
-*   Always read the entire thread before replying. Seriously, read every message in a thread first!
-*   Don't use the mailing list as your own personal Google. Take the time to research the question first. Check the archives, search the project documentation first, Google it yourself.
-*   Don't begin or get involved in religious or political arguments.
-*   Never proselytize on the mailing list.
-*   Do your best to always assume the best of the poster. We all have bad days. Sometimes, a non-native speaker may appear to have an offensive "tone" in the post where no offense is meant.
-*   Avoid unintentional "tone" in your postings. If you have any doubt read your message out loud or have someone else read your message before you post.
-
+* Follow the mailing list posting style. Do people top or bottom post? Follow the norm.
+* Keep your posts on-topic. Avoid tangents and posting "I know this is off-topic but..." type posts. If you have any doubt, email the moderator *before* you post.
+* Don't cross-post to multiple lists. Communicating well on mailing lists means knowing where and when to post items, if you have any doubts regarding what is appropriate, ask the moderator.
+* Never send community members unsolicited personal messages. Especially, if your content is along the lines of "the way you talk about code really turns me on." Inappropriate!
+* If you are offended by a response or post, walk-away. Do not respond when you are angry.
+* Avoid posting to the mailing list if you are significantly under the influence of anything that makes you behave out of your norm. Just like drunk-dialing is bad -- so is drunk emailing to your open source community mailing list.
+* Avoid profanity.
+* Don't post chain letters, marketing messages or other types of non-topical spam.
+* Always check the archives before re-posting your message. Lots of mail clients don't send you duplicates of your mailing lists posts. Check the archives before you re-send!
+* Always read the entire thread before replying. Seriously, read every message in a thread first!
+* Don't use the mailing list as your own personal Google. Take the time to research the question first. Check the archives, search the project documentation first, Google it yourself.
+* Don't begin or get involved in religious or political arguments.
+* Never proselytize on the mailing list.
+* Do your best to always assume the best of the poster. We all have bad days. Sometimes, a non-native speaker may appear to have an offensive "tone" in the post where no offense is meant.
+* Avoid unintentional "tone" in your postings. If you have any doubt read your message out loud or have someone else read your message before you post.
 
 ## Like a bullhorn
 
-When you post to the GSoC student list you are essentially using a bullhorn to broadcast your words to 7,000 people across time zones and international boundaries. Use your bullhorn wisely, or it might be ripped from your hands by an unruly and angry mob, or by a responsible moderator.
-
+When you post to the GSoC contributor list you are essentially using a bullhorn to broadcast your words to 10,000 people across time zones and international boundaries. Use your bullhorn wisely, or it might be ripped from your hands by an unruly and angry mob, or by a responsible moderator.
 
 ## How to Use IRC
 
@@ -52,10 +59,8 @@ The Fedora Project has a great FAQ on how to use IRC. Read it!
 
 Some additional guidelines:
 
-*   Include your real name in your IRC signature information.
-*   Never private-message (pm) someone that you don't know without first asking if it is OK in the public channel.
-*   Read the topic before asking questions.
-*   Stay on-topic for the channel.
-*   Before asking questions in #gsoc - read the FAQ!
-
-
+* Include your preferred name in your IRC signature information.
+* Never private-message (pm) someone that you don't know without first asking if it is OK in the public channel.
+* Read the topic before asking questions.
+* Stay on-topic for the channel.
+* Before asking questions in #gsoc - read the FAQ!
diff --git a/pages/student/12-how_to_get_a_head_start.md b/pages/student/12-how_to_get_a_head_start.md
index a9c0eeba..f2edea9f 100644
--- a/pages/student/12-how_to_get_a_head_start.md
+++ b/pages/student/12-how_to_get_a_head_start.md
@@ -8,48 +8,43 @@ sidebar: student_sidebar
 
 The last thing you want is for the coding period to start and then realize that you don't have all the tools you need installed and configured to actually begin work. Don't let this happen to you! The community bonding period is the perfect time to get these things sorted out.
 
-
 ## Get Your Development Environment in Order
 
 Each project has a unique set of tools and packages required to work with developers. These often include:
 
-*   Compiler
-*   Language interpreter
-*   Text editor
-*   Version control system
-*   Modules and libraries needed by the software
-*   Database, mail or web server
-*   Real-time communication tool (e.g. irc client, instant messaging)
+* Compiler
+* Language interpreter
+* Text editor
+* Version control system
+* Modules and libraries needed by the software
+* Database, mail or web server
+* Real-time communication tool (e.g. irc client, instant messaging)
 
 Some organizations require testing on multiple operating systems and/or platforms. Make sure you know what is expected of you as early as possible. Read the available development documentation and contact your mentor to figure out exactly what tools you need to succeed. Also learn the bug-reporting process that your organization uses and understand the project's release management strategy.
 
-
 ## Practice
 
 Once you get your development environment setup start practicing! This includes getting familiar with the coding standards, codebase, and testing and documentation policies of the open source project community. Do a few practice commits and work on understanding how source control works within your project. Brush up on any new skills and start asking questions.
 
-
 ## Do Some Background Research
 
 Look through the projects bug database and read through the user list to understand your end users. Peruse the mailing list archives and go through the project's existing documentation.
 
-
 ## Start Interacting
 
-Take advantage of the community bonding period to connect with your mentor, and other students in the program. Set up a blog, get involved on relevant forums and mailing lists and in general, start interacting with the development community. Make sure you have what you need to succeed, and if you don't, ask your mentor for help.
+Take advantage of the community bonding period to connect with your mentor, and other GSoC contributors. Set up a blog, get involved on relevant forums and mailing lists and in general, start interacting with the development community. Make sure you have what you need to succeed, and if you don't, ask your mentor for help.
 
+## Start Working with Your Fellow GSoC contributors
 
-## Start Working with Your Fellow Students
+GSoC is not only about working with your mentor. There's this amazing group of outstanding and motivated GSoC contributors too.
 
-GSoC is not only about working with your mentor. There's this amazing group of outstanding and motivated students too.
+**GSoC Contributor/Student mailing list**
 
-**Student mailing list**
-
-Google has a private mailing list for the GSoC students. Go ahead and introduce yourself on the student mailing list. Talk about your project ideas, get feedback on your proposal. The mailing list also has GSoC participants from earlier lists. Use the student mailing list as an additional resource. Your questions can be technical or non-technical. Of course, remember not to be a bullhorn and be mindful of the mailing list etiquette.
+Google has a private mailing list for the GSoC contributors/students. From 2005-2021 GSoC was focused on students hence keeping the student in the list name. The mailing list also has GSoC participants from earlier lists. Use the GSoC contributor/student mailing list as an additional resource. Your questions can be technical or non-technical. Of course, remember not to be a bullhorn and be mindful of the mailing list etiquette. Please don't "+1" on the mailing list as you are spamming thousands of people and will likely have the message moderated.
 
 **They're just like me!**
 
-There are many students who have faced or are facing the problems like you. Don't be scared to ask your questions. This is more true for the students who have been accepted to the same organizations as yours. You can ask them about how they got their dev setup working. Help each other out on the irc and mailing lists. Don't be afraid to ask and don't be afraid to answer!
+There are many GSoC contributors who have faced or are facing problems like you. Don't be scared to ask your questions. This is more true for the GSoC contributors who have been accepted to the same organizations as yours. You can ask them about how they got their dev setup working. Help each other out on the chat channels and mailing lists. Don't be afraid to ask and don't be afraid to answer!
 
 **Make friends around the world**
 
@@ -57,15 +52,12 @@ GSoC is a great opportunity that helps people and communities collaborate across
 
 **Meetup and discussion groups**
 
-You can always find students who are excited by the same ideas as yours. Use your GSoC contacts to organize meetups and discussion groups. You can meet up with people who are. It's always good to put a face on the names that you've been friends with. Help each other out with coding problems.
+You can always find GSoC contributors who are excited by the same ideas as yours. Use your GSoC contacts to organize meetups and discussion groups. You can meet up with people who are interested in the same things as you. It's always good to put a face to the names that you've been friends with. Help each other out with coding problems.
 
 **Organize Student Chapters**
 
 You can even consider starting a local student chapter for your community if you can find enough interested people. It's a great way of socializing, making and keeping new friends and also spreading word about your community, open source and GSoC.
 
-
 ## Review Your Project Plan
 
-Do you have a good project schedule? Have you informed your mentor of any planned absences? Make any project adjustments you may now recognize as necessary based upon getting your dev environment setup and your new understanding of how the project works.
-
-
+Do you have a good project schedule? Have you informed your mentor of any planned absences? Make any project adjustments you may now recognize as necessary based upon getting your dev environment setup and your new understanding of how the project works. With the flexibility in extending your program timeline that is being offered, this is a crucial time to let your mentor know if your plans changed since you first wrote your proposal and now you will have limited availability for X weeks for whatever reason. Communicate with your mentor. They want you to succeed but you have to let them know you have some varying availability during the summer. It's okay as long as you let them know as soon as you can so you both can work on a reasonable schedule and project milestones together.
diff --git a/pages/student/13-working_with_your_mentor.md b/pages/student/13-working_with_your_mentor.md
index ab16eda4..a73b2d72 100644
--- a/pages/student/13-working_with_your_mentor.md
+++ b/pages/student/13-working_with_your_mentor.md
@@ -8,11 +8,9 @@ sidebar: student_sidebar
 
 Once your project is accepted you are assigned a primary mentor and potentially secondary mentors as well. Consistent access to mentors is one of the most valuable parts of the GSoC program. Your mentor is going to work with you throughout the GSoC program to help you be successful, but you also need to make sure you are contributing to and helping to manage your relationship with your mentor.
 
-
 ## Community Bonding Period
 
-The community bonding period is when you work out further details of your project plan, schedule regular upcoming meetings with your mentor, get your development environment set up and start to engage with the project's open source community. This is the time to work with your mentor on setting expectations for your interactions and how your progress is measured during the GSoC program. Hopefully, you have already participated in many discussions with your mentor, clarifying the project and expectations during the application period, but now is the time to finalize your plans.
-
+The community bonding period is the essential period of the program when you work out further details of your project plan, schedule regular upcoming meetings with your mentor, get your development environment set up and start to engage with the project's open source community. This is the time to work with your mentor on setting expectations for your interactions and how your progress is measured during the GSoC program. Hopefully, you have already participated in many discussions with your mentor, clarifying the project and expectations during the application period, but now is the time to finalize your plans.
 
 ## Staying on Track
 
@@ -20,19 +18,16 @@ Ideally, you have already worked with your mentor to layout a clear schedule for
 
 Your mentors are busy people too. They are juggling many tasks and GSoC is one more added to their load. If you rely solely on your mentor to keep track of and enforce the schedule of work, your project is almost guaranteed to fail. Be proactive in keeping the schedule you've agreed to and proposing modifications before deadlines pass.
 
-
 ## Be Respectful of Your Mentor's Time
 
 Your mentor is volunteering their time to help you with your GSoC project. Regularly missing scheduled meetings without prior notice and failing to come prepared to meetings is likely to cause your mentor to not want to continue helping you with your project. Remember your mentor is your most valuable resource to help you complete your project successfully, treat them accordingly.
 
-
 ## Using Your Mentor
 
 During the coding period, you should continue to make full use of your mentor. As you implement each phase of your project plan, ask your mentor for feedback on the code as you go. Avoid working for two weeks on a chunk of code that is headed in the wrong direction.
 
 Never be afraid to ask questions, but remember you are going to be more successful in receiving a good answer if you try to be specific and do a bit of background investigation first. Take a look at logs and try to think through the error or problem before asking for help. Equally important is to not wait until you are significantly behind in your project to ask for help.
 
-
 ## Asking For and Receiving Feedback
 
 Hearing criticism can be hard. It can be even harder to not respond defensively. Asking for and receiving constructive criticism about your project from your mentor, the larger open source project community and your peers is an invaluable exercise to help you write the best code possible.
@@ -45,7 +40,6 @@ During the community bonding period you and your mentor should have established
 
 First, take a deep breath. OK, now take another. Chances are your mentor is not wrong and you need to listen to their advice. This is a great opportunity to start asking questions. Try not to be defensive but rather, "I really don't understand what you mean, would you please explain?". Remember that the open culture surrounding most open source projects encourages and thrives on discourse. Don't view the feedback as negative criticism, but rather an opportunity to explore how to do something different and make your project better. Do your best to listen, learn and incorporate feedback into how you work.
 
-
 ## Dealing with Problems
 
 One of the best things you can do when working to solve real or perceived problems with your mentor relationship is to stop and remember that your mentor(s) is a volunteer and has non-GSoC responsibilities.
@@ -67,5 +61,3 @@ Remember that everyone has different communication styles and you might both be
 **Why is my mentor so friendly?**
 
 Again, this could be a disconnect based on different communication techniques within different cultures. Make sure you let your mentor know what about their style is making you uncomfortable. If things don't change for the better, contact your org admin.
-
-
diff --git a/pages/student/14-time_management_for_students.md b/pages/student/14-time_management_for_students.md
index a7f355b6..e04649ae 100644
--- a/pages/student/14-time_management_for_students.md
+++ b/pages/student/14-time_management_for_students.md
@@ -1,5 +1,5 @@
 ---
-title: Time management for students
+title: Time management for contributors
 section: Let The Coding Begin
 order: 14
 permalink: student/time-management-for-students.html
@@ -8,15 +8,17 @@ sidebar: student_sidebar
 
 Well, 12 weeks isn't a lot of time to write all the code and have all the fun that you're supposed to have during GSoC. Efficient time management goes a long way in helping you make the most of your GSoC experience. Even though Google puts out a timeline for making sure that things do happen on time, you and your mentor should come up with a custom time line that fits in well with your project requirements and also with your plans for the summer.
 
+You and your mentor can decide together (with the organization administrator's approval) that you wish to extend the project longer than the standard 12 weeks (for medium and large projects) up to 22 weeks. Be sure you have a clear path and expectations on how the work will be divided over this new adjusted timeframe. Maybe there is a full month in the middle where you have finals or are expecting a child and know you won't be able to fully commit to GSoC during that time, that can be okay as long as you and your mentor have agreed on a plan together.
+
 The following are some suggestions that can help you to manage your time well:
 
 **Community Bonding Period**
 
-There's already a complete section in the manual on this. (It is *that *important.) Use this time to get familiar with your community, setup your development environment and get an early start on the code development. This is time where you're getting to know your mentor and other students. Chat with them on IRC, ask questions and share ideas on projects and get ready to begin the fun ride ahead.
+There's already a complete section in the guide on this. (It is *that* important.) Use this time to get familiar with your community, setup your development environment and get an early start on the code development. This is time where you're getting to know your mentor and other GSoC contributors. Chat with them in chat rooms, ask questions and share ideas on projects and get ready to begin the fun ride ahead.
 
 **Be upfront about your time commitment**
 
-GSoC needs an investment of about 30 hours a week. If you know in advance that you'll need to take a couple of days of vacation/break during the Summer of Code, you should communicate that with your mentor beforehand and plan to make up for lost days.
+GSoC needs an investment of about 90 hours for small projects, 175 hours for medium size projects and 350 hours for large projects. If you know in advance that you'll need to take a few days or even weeks of vacation/break during the Summer of Code, you should communicate that with your mentor beforehand and plan to make up for lost days by extending the standard 12 week program or having heavier coding weeks to accommodate the missed time. You and your mentor have the opportunity to add some flexibility into your schedule up to a point. However, you both will need to agree on any planned breaks, an adjusted end date for your project, etc.
 
 **Regular meetings with your mentor**
 
@@ -24,11 +26,11 @@ You should absolutely, absolutely make sure you're interacting often with your m
 
 **Have mini-goals for each week**
 
-It always helps to set short-term goals that you can discuss with your mentor. Breaking down your project in smaller tasks helps in many ways:
+It always helps to set short-term goals that you can discuss with your mentor. Breaking down your project into smaller tasks helps in many ways:
 
-*   It gets you started!! You have a smaller, well-defined task to work on which is easier to manage.
-*   Mini-goals help create a road map to get to the final output you're trying to produce.
-*   Smaller goals are less daunting, and completing a small goal gives you the confidence to tackle the next one.
+* It gets you started!! You have a smaller, well-defined task to work on which is easier to manage.
+* Mini-goals help create a road map to get to the final output you're trying to produce.
+* Smaller goals are less daunting, and completing a small goal gives you the confidence to tackle the next one.
 
 **Regular code reviews**
 
@@ -47,5 +49,3 @@ It's very likely that your mentor is in a different time zone than you are. Be s
 Things usually don't go the way you plan them. Make sure you have room for the unplanned changes. It's always best to keep aside some buffer time that you can use in case you do digress from your original plan and save yourself from considerable pain and panic attacks.
 
 Of course, do remember that GSoC is not just all coding and working. It's about having fun too! If you manage your time well, you will have a great Summer of Code, meet interesting people and have lots of fun.
-
-
diff --git a/pages/student/15-evaluations.md b/pages/student/15-evaluations.md
index 1a39420b..c10e9d08 100644
--- a/pages/student/15-evaluations.md
+++ b/pages/student/15-evaluations.md
@@ -6,21 +6,19 @@ permalink: student/evaluations.html
 sidebar: student_sidebar
 ---
 
-Evaluations occur three times (after the first, second and third months of coding). They are your opportunity to evaluate your mentor and your mentoring organization's performance. This is also your mentor's opportunity to evaluate you.
+Evaluations occur two times: at the midpoint of the program and at the end of the program after you submit your final work product. For the standard 12 week project your first evaluation will be at the end of 6 weeks and the end final evaluation will be after the 12th week of the coding period. For the small projects, the midterm will be after 4 weeks and the final work submission from the GSoC contributor will be after 8 weeks. The evaluations are your opportunity to evaluate your mentor and your mentoring organization's performance. This is also your mentor's opportunity to evaluate you.
 
 The pass or fail decision from an evaluation should not come as a surprise. You and your mentor will already be communicating, and you should be discussing the quality of your code, your participation in the community and your progress on your project to that point. If you aren't getting this feedback, ask for it.
 
-
 ## How Evaluations Work
 
 Evaluations are a survey that both you and your mentor fill in during the evaluation period. Google publishes the evaluation questions for both students and mentors in advance.
 
-Evaluations are administered via the webapp you used to submit your project proposal at the start of the term. Evaluations will take about 10-15 minutes to complete. The questions focus on the scope of your project, the quality of your interactions with your mentor and your community. You, your mentor and org admins will receive an email after the evaluation window closes that tells you whether you've passed.
-
-Your evaluations are only visible to your mentoring org admins and program administrators from Google. In some cases, Google's program administrators may need to share some details of evaluations with you and your mentor. This may happen, for example, when evaluations indicate a payment should not be made.
+Evaluations are administered via the webapp you used to submit your project proposal at the start of the term. Evaluations will take about 10-15 minutes to complete. The questions focus on the scope of your project, the quality of your interactions with your mentor and your community. You, your mentor, and org admins will receive an email after the evaluation window closes that tells you whether you've passed.
 
-If you do not submit an evaluation, you fail and will be removed from the program. Similarly, failing an evaluation means you are immediately removed from the GSoC program.
+Your evaluations have multiple questions on them that are clearly marked who can view the answers. In most cases only Google program administrators can see your responses. There are a few clearly labeled questions that the organization administrators of your organization can see to help them understand if the mentors are fulfilling their roles and responsibilities to you. In very rare cases, Google's program administrators may need to share some details of evaluations with you and your mentor. This may happen, for example, when evaluations indicate a payment should not be made (a GSoC contributor should be failed).
 
+You are encouraged to complete both evaluations but you are only required to complete the final evaluation. If you do not complete the final evaluation which also includes your link to your work product you will fail the program. Failing an evaluation means you are immediately removed from the GSoC program without receiving a stipend.
 
 ## Final Evaluations and Work Product Submission
 
@@ -28,9 +26,6 @@ At the end of the Google Summer of Code term you are required to provide a link
 
 Depending on what portions of code are included in the scope of your project, you may need to submit diffs between code that you've written and others have written, or even include an entire branch of the code base. Discuss this with your mentor and your community and use your best judgement.
 
+## Payments - Be Patient
 
-## Payments - Be Patient!
-
-Successful completion of your evaluations triggers the payments to your account or your payment card. This takes a few business days to process. Please be patient.
-
-
+Successful completion of your evaluations triggers the payments to your Payoneer account. This can take a few business days to process. Please be patient.
diff --git a/pages/student/16-strategies_for_getting_your_code_committed.md b/pages/student/16-strategies_for_getting_your_code_committed.md
index 44356531..b2f6d5e4 100644
--- a/pages/student/16-strategies_for_getting_your_code_committed.md
+++ b/pages/student/16-strategies_for_getting_your_code_committed.md
@@ -8,17 +8,15 @@ sidebar: student_sidebar
 
 A key goal of GSoC is to produce useful code that is integrated into the code base of your community. Every organization has different standards for code submissions, but there are some general rules you can follow that will help make your code easier to integrate:
 
-*   Follow the documentation guidelines. Some organizations have a policy that code must have some documentation before it can be committed.
-*   Make sure the tests pass! You have tests, right?
-*   Include lots of useful comments in your code. Comments make people happy.
-*   Tests are sensitive to the versions of software, operating system and libraries you are using. It is a good idea to run your tests on a few of the most commonly used versions of libraries or prerequisites, if possible.
-*   Document exactly what kind of environment you wrote the code in, and whether certain things may be dependent on your operating system or platform. For example: "This patch was tested on Linux x86 and OS X Intel, but may have some issues with FreeBSD"
-*   Read through recent commits to the repository that you would like your code to be in. You will often learn about something relevant to your code, such as a macro that makes your life easier or a special trick for avoiding bugs.
-*   Commit often. You can always maintain a local branch of the code to which you keep committing regularly. This keeps you from losing work; it also gives you something concrete to show your mentor and get feedback on.
-*   Take the feedback on your code positively. Appreciate the comments and suggestions you receive and use them for your next commit. It certainly helps you write better code and grow as a developer.
+* Follow the documentation guidelines. Some organizations have a policy that code must have some documentation before it can be committed.
+* Make sure the tests pass! You have tests, right?
+* Include lots of useful comments in your code. Comments make people happy.
+* Tests are sensitive to the versions of software, operating system and libraries you are using. It is a good idea to run your tests on a few of the most commonly used versions of libraries or prerequisites, if possible.
+* Document exactly what kind of environment you wrote the code in, and whether certain things may be dependent on your operating system or platform. For example: "This patch was tested on Linux x86 and OS X Intel, but may have some issues with FreeBSD"
+* Read through recent commits to the repository that you would like your code to be in. You will often learn about something relevant to your code, such as a macro that makes your life easier or a special trick for avoiding bugs.
+* Commit often. You can always maintain a local branch of the code to which you keep committing regularly. This keeps you from losing work; it also gives you something concrete to show your mentor and get feedback on.
+* Take the feedback on your code positively. Appreciate the comments and suggestions you receive and use them for your next commit. It certainly helps you write better code and grow as a developer.
 
 There's something really satisfying and fulfilling about getting your code accepted and seeing it used by many others. Getting your code submitted is your first step towards achieving that accomplishment! More importantly, it helps you in honing your skills as a great developer and contributor.
 
-**Pro Tip**: You can also ask other students to review your code for you and give you feedback. Use other students in your community and the GSoC program as a resource.
-
-
+**Pro Tip**: You can also ask other GSoC contributors to review your code for you and give you feedback. Use other students in your community and the GSoC program as a resource.
diff --git a/pages/student/17-staying_engaged_with_your_community.md b/pages/student/17-staying_engaged_with_your_community.md
index ecda6d37..81ae0b13 100644
--- a/pages/student/17-staying_engaged_with_your_community.md
+++ b/pages/student/17-staying_engaged_with_your_community.md
@@ -8,47 +8,38 @@ sidebar: student_sidebar
 
 A glorious summer has ended. GSoC is now over—but only officially. Your obligation to the program has been met, but your opportunities still abound. Make the "summer" last by staying involved in your community. Yes, it's now *your* community. Make the most of it. We have a couple of suggestions that can help you make your experience last beyond the summer.
 
-
 ## Maintaining Your Project
 
-You worked on a wonderful project during the summer. You can't abandon it just because the summer ended! After all it's your *baby*. One way to make sure that your project keeps on growing is by maintaining it well, adding new features to it. There might be a few loose ends that you weren't able to tie up during the coding period. If there's anything in (or not in) your code that's keeping you awake at night, you can always work on that after the coding period ends.
+You worked on a wonderful project during the summer. You can't abandon it just because the summer ended! After all, it's your *baby*. One way to make sure that your project keeps on growing is by maintaining it well, adding new features to it. There might be a few loose ends that you weren't able to tie up during the coding period. If there's anything in (or not in) your code that's keeping you awake at night, you can always work on that after the coding period ends.
 
 "Please do the communities a favour by not abandoning your projects after the GSoC results are announced, or the boogeyman will get you.[!!!] "
 
-Lalith Suresh P., Network Simulator 3, GSoC Student 2010
-
+Lalith Suresh P., Network Simulator 3, GSoC Student
 
 ## New Projects
 
 Do you have other amazing ideas for projects? Why wait until next GSoC to get started on them. You should start working on them right away. You know the folks in your community well now, and you know where to shout for help. Just get started on your wonderful new project idea; you can even get it accepted as a GSoC project next year!
 
-
 ## Retreats and Hackfests
 
 A lot of organizations host opportunities to meet face-to-face throughout the year. Attend if there's one happening close by. They're great fun! In fact, you can help organize such activities or even start a local chapter of your community in your area if you have enough people around.
 
-
 ## Spread the word
 
 You had a great time this summer. It's your turn now to tell your friends about it. GSoC is also about growing the open source community. Share your GSoC success story with others and inspire them too!
 
-
 ## Present your work
 
 You can present your project at some of the open source conferences. The open source community is very much interested in finding out about the cool things that people have been working on. Conferences are a great way of doing that. If possible, you should attend a conference and use the opportunity of presenting your project to other people. It gets you great feedback on your project and helps you find out about other cool things happening in the open source world.
 
-
 ## Next Summer
 
-There are so many ways that you can help your organization and the open source community for the next Google Summer of Code. You can submit project ideas, apply again as a student or even become a mentor for a project. You can even contribute by just idling in the IRC channels, helping out the new students who come looking for advice.
-
+There are so many ways that you can help your organization and the open source community for the next Google Summer of Code. You can submit project ideas, apply again as a GSoC contributor or even become a mentor for a project. You can even contribute by just idling in the chat channels, helping out the new folks who come looking for advice.
 
 ## Stay connected
 
-Everyone likes to hear back from friends and people they've worked with. Be sure to stay in touch with your mentors, other students and the many great friends that you've made during GSoC.
+Everyone likes to hear back from friends and people they've worked with. Be sure to stay in touch with your mentors, other GSoC contributors and the many great friends that you've made during GSoC.
 
 "GSoC may be over, but I'm really hoping my contribution to the Congress application will go beyond that. I'll be sure to stay in touch with Eric and the Sunlight Foundation. "
 
-Evelina Vrabie, SunLight Foundation, GSoC Student 2010
-
-
+Evelina Vrabie, SunLight Foundation, GSoC Student
diff --git a/pages/student/18-about_this_manual.md b/pages/student/18-about_this_manual.md
index f0eedd1f..918f6c42 100644
--- a/pages/student/18-about_this_manual.md
+++ b/pages/student/18-about_this_manual.md
@@ -17,14 +17,15 @@ An update of the manual was done in December 2017 and what was quite impressive
 is how few changes had to be made as all of the advice the original authors gave
 in this manual still stand today.
 
-In October 2017, the guide moved from <http://www.flossmanuals.net> to GitHub.
+Another update was done in November 2021 to reflect the eligibility and
+flexibility changes to the GSoC program for 2022.
 
+In October 2017, the guide moved from <http://www.flossmanuals.net> to GitHub.
 
 ## How to Contribute to This Manual
 
 See the CONTRIBUTING file in the source repository.
 
-
 ## About the Authors
 
 Except where noted, the following individuals were part of both the 2009 and 2010 GSoC Book Sprint. We thank them for their tireless efforts to create this first-of-its-kind volume.
@@ -61,7 +62,7 @@ Selena is a major contributor to the PostgreSQL project. She founded Open Source
 
 **Carol Smith**
 
-Carol works for the Open Source Programs Office at Google administering the Google Summer of Code program. She has worked at Google for 5 years in a variety of positions. She has a degree in photojournalism from California State University, Northridge and is an avid cyclist.
+Carol worked for the Open Source Programs Office at Google administering the Google Summer of Code program. She worked at Google for 6+ years in a variety of positions. She has a degree in photojournalism from California State University, Northridge and is an avid cyclist.
 
 <http://www.fossygirl.com>
 
@@ -71,6 +72,9 @@ Malveeka is currently a graduate student in the CS dept at UC, San Diego. She pa
 
 <http://cseweb.ucsd.edu/~mtewari/>
 
+**Stephanie Taylor** (2011-current)
+
+Stephanie is the GSoC lead (since 2015) and has worked at Google in the Open Source Programs Office since 2011. Stephanie also led the Google Code-in program for teens that ended in 2020. Stephanie loves adventure travel and discovering the best hot chocolates around the world.
 
 ## 2009 Participants
 
@@ -86,7 +90,6 @@ Leslie held various roles at Google before joining the Open Source Programs Offi
 
 <http://www.hawthornlandings.org>
 
-
 ## Facilitation (2009 & 2010)
 
 The Book Sprints were facilitated by:
@@ -95,5 +98,4 @@ The Book Sprints were facilitated by:
 
 Adam is the founder of FLOSS Manuals and project manager for Booki. FLOSS Manuals is a community of 1500 (at the time of writing) volunteers that create quality free documentation about free software. FLOSS Manuals is pioneering the Book Sprint methodology that enables the development of well written manuals on free software in 2-5 days. Adam has facilitated over 15 Book Sprints on Free Software including Inkscape, OLPC, Sugar, CiviCRM, Firefox, Introduction to the Command Line, Digital Foundations (conversion to free software examples), Ogg Theora, How to Bypass Internet Censorship, Open Translation Tools, PureData, Video Subtitling and now the Google Summer of Code Mentors Guide. Adam is also the Project Manager for the development of 'Booki' - the free software Collaborative Authoring Platform (see below).
 
-adam@flossmanuals.net
-
+<adam@flossmanuals.net>
diff --git a/pages/student/19-history_of_gsoc.md b/pages/student/19-history_of_gsoc.md
index f26395e4..5981566b 100644
--- a/pages/student/19-history_of_gsoc.md
+++ b/pages/student/19-history_of_gsoc.md
@@ -14,8 +14,10 @@ The perfect answer came from encouraging students to participate in open source
 
 A cash stipend from Google allowed students to focus on their development work rather than getting a job unrelated to their academic pursuits. The final part of the puzzle was finding projects who were excited to find new contributors and to provide helpers to get these new folks up to speed both technically and socially. The first year 40 projects participated; 400 students began the experiment.
 
-In 2019, the fifteenth Google Summer of Code wrapped up with more than 89% of the 1267 student participants in the program successfully completing their projects. Best of all, most of the organizations participating over the past fifteen years reported that the program helped them find new community members and active committers.
+In 2021, the seventeenth Google Summer of Code wrapped up with more than 94% of the 1198 student participants in the program successfully completing the program. Best of all, most of the organizations participating over the past seventeen years reported that the program helped them find new community members and active committers. 99% of 2021 students said they planned to continue to contribute to open source post-GSoC.
 
-You can find more information about each year of Google Summer of Code on the program statistics page on the History tab of the GSoC website: <https://developers.google.com/open-source/gsoc/resources/stats>
+In 2022, we opened the program to non-student developers as well and we are excited to see what great things our new GSoC contributors will do with our open source organizations. We also have multiple size project options available for folks, with the understanding not everyone can dedicate 350 hours to an open source project during GSoC so there will also be 175 hour projects available for GSoC contributors to work on in 2022. The final update to the program is more flexibility around the schedule for a GSoC contributor project. Instead of everyone having to complete the project in 12 weeks, GSoC contributors and their mentors can decide to extend the end date of their project (up to 22 weeks) to better fit the GSoC contributor's commitments for the summer. We look forward to these updates helping even more people excited to learn about open source under the guidance of dedicated mentors participate in GSoC.
 
+In 2024 we are celebrating 20 years of GSoC! We have added small size projects (~90 hours) for a standard 8 weeks, now allowing GSoC contributors to work on small (90 hour), medium (175 hour) or large (350 hour) projects. We are excited to see more students and early career developers involved with the program.
 
+You can find more information about each year of Google Summer of Code on the program statistics page on the History tab of the GSoC website: <https://developers.google.com/open-source/gsoc/resources/stats>
diff --git a/pages/student/20-additional_resources.md b/pages/student/20-additional_resources.md
index 3b5e59e7..d8fdc478 100644
--- a/pages/student/20-additional_resources.md
+++ b/pages/student/20-additional_resources.md
@@ -8,16 +8,18 @@ sidebar: student_sidebar
 
 We've collected our favorite and most useful resources specific to GSoC here.
 
-
 ## General Resources
 
 Take a look at the Program Rules and Frequently Asked Questions to make sure you understand the rules of the program. There's also a wealth of information included in the FAQs and this guide, even for experienced participants. You can always find the latest information on the program site: <https://g.co/gsoc>
 
 Additionally, these resources are quite helpful:
 
+**Program Discord Channel**
+We have a new Google Summer of Code Discord channel (discord.gg/google-dev-community) that is a space to talk about open source and the exciting things folks are learning, tips for others, and also ask others for suggestions if you are stuck, etc. It is not a support channel. For support from a Google Program Administrator, email <gsoc-support.com>.
+
 **Program IRC Channel**
 
-Several knowledgeable folks (mentors, org admins, former students, current students and Google Program Admins) hang out in #gsoc on Freenode and would be happy to give you a pointer in the right direction. And many organizations have their own IRC channels that you can hang out in.
+Several knowledgeable folks (mentors, org admins, former students, current contributors) hang out in #gsoc on [Libera.Chat](https://web.libera.chat/?channels=#gsoc) and would be happy to give you a pointer in the right direction. And many organizations have their own IRC channels that you can hang out in.
 
 **Blog Posts**
 
@@ -31,10 +33,9 @@ If you're looking for advice for mentors or students, program promotional materi
 
 You can see a list of the mentoring organizations that participated in previous years of the program by going to the program site and looking at the Archive site: <https://developers.google.com/open-source/gsoc/past-summers>
 
-
 ## Mailing Lists
 
-There are two program mailing lists.
+There are three program mailing lists.
 
 **Announcement Only List**
 
@@ -48,6 +49,9 @@ Open subscription list for the program. General talk about the program, light tr
 
 <http://groups.google.com/group/google-summer-of-code-discuss>
 
+**GSoC Contributor List**
+
+We have a program list for all accepted GSoC contributors. We add folks to the list based on their opting in to the GSoC Contributor list when registering for the program. This is only for current GSoC contributors and GSoC contributors/students that passed the program in previous years.
 
 ## Books
 
@@ -67,19 +71,14 @@ by Karsten Wade
 
 <http://teachingopensource.org>
 
-
 ## Associated Projects
 
 **Teaching Open Source**
 
 <http://teachingopensource.org>
 
-irc : freenode #teachingopensource
-
-
 ## What to Do When the Unexpected Happens?
 
-1.  Contact your Mentor. He or she can help you figure out what to do next or contact Google for more help.
-1.  Contact the Org Admin.
-1.  Talk to Google's Program Administrators. They have plenty of experience with all the corner cases and strange issues that can arise during GSoC.
-
+1. Contact your Mentor. He or she can help you figure out what to do next or contact Google for more help.
+1. Contact the Org Admin.
+1. Talk to Google's Program Administrators. They have plenty of experience with all the corner cases and strange issues that can arise during GSoC.
diff --git a/pages/student/21-proposal_example_1.md b/pages/student/21-proposal_example_1.md
index 9c95da50..2eea82be 100644
--- a/pages/student/21-proposal_example_1.md
+++ b/pages/student/21-proposal_example_1.md
@@ -8,67 +8,63 @@ sidebar: student_sidebar
 
 "Database Abstractions" By Kanika Vats, Systers, 2009
 
-
 ## Abstract
 
 Systers use GNU mailing list manager Mailman2 which currently uses Python pickle files to store its data. Systers moderators have customized it to make use of PostgreSQL database. They make use of raw SQL statements and python db-api which makes the code :
 
-*   Dependent on the existing database
-*   Reduces the efficiency and maintainability
+* Dependent on the existing database
+* Reduces the efficiency and maintainability
 
 The project idea aims at making the code :
 
 Independent of the database by making the use of python classes and objects to interact with the database rather than direct SQL statements.
 
-*   This will be achieved with the help of an ORM (Object Relational Mapper). Storm will be our choice of ORM.
-*   Also, Systers aim at bringing this feature upstream and incorporating this feature in the yet to be released version - Mailman3 (which will switch to use a database) - so that the open source world can benefit themselves with the addition of this feature.
+* This will be achieved with the help of an ORM (Object Relational Mapper). Storm will be our choice of ORM.
+* Also, Systers aim at bringing this feature upstream and incorporating this feature in the yet to be released version - Mailman3 (which will switch to use a database) - so that the open source world can benefit themselves with the addition of this feature.
 
 Thus, mapping existing schemas of the Systers database to an object oriented paradigm and determination and incorporation of necessary modifications in the database needs to be done so that it fits cleanly and nicely into Mailman3's Architecture.
 
-
 ## Proposal Timeline
 
 **Before April 20:**
 
-*   To familiarize myself completely with Mailman2's functionality and architecture.
-*   Study of the customized files of Systers Mailman available in the Launchpad Baazar version control.
-*   To familiarize myself with Storm(ORM that we will be using)
+* To familiarize myself completely with Mailman2's functionality and architecture.
+* Study of the customized files of Systers Mailman available in the Launchpad Baazar version control.
+* To familiarize myself with Storm(ORM that we will be using)
 
 **April 20 – May 23 (Before the official coding time):**
 
-*   To do self coding with Storm to improve my further understanding and ease of use with this ORM and database(PostgreSQL)
-*   During this period I will remain in constant touch with my mentor and the Mailman community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing schemas and design of new schemas (if needed to fit cleanly with Mailman3's Architecture)
-*   Thus with the help of my mentor I will become absolutely clear about my future goals,the final database implementations that need to be done as well as the approach that I will follow to map the schemas to the Object Oriented Paradigm.
+* To do self coding with Storm to improve my further understanding and ease of use with this ORM and database(PostgreSQL)
+* During this period I will remain in constant touch with my mentor and the Mailman community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing schemas and design of new schemas (if needed to fit cleanly with Mailman3's Architecture)
+* Thus with the help of my mentor I will become absolutely clear about my future goals,the final database implementations that need to be done as well as the approach that I will follow to map the schemas to the Object Oriented Paradigm.
 
 **May 23 – June 18 (Official coding period starts):**
 
-*   Define all the required Relations(Tables) in my local database using STORM.
-*   Define all the corresponding Python Classes and Objects that will store,modify and retrieve data in database.
-*   Define all the interactions that Systers perform with their database (virtualize or stimulate all interactions) in STORM that will deal with my local database.
+* Define all the required Relations(Tables) in my local database using STORM.
+* Define all the corresponding Python Classes and Objects that will store,modify and retrieve data in database.
+* Define all the interactions that Systers perform with their database (virtualize or stimulate all interactions) in STORM that will deal with my local database.
 
 This will help in testing of the proper working of the entire basic code changes that we will later on incorporate in Systers Source code.
 
 **June 18 – July 5:**
 
-*   Bringing about the decided changes in the Relational Schemas of Systers database.
-*   Replacing parts of the above code in their respective places in the Systers source code. (This should not take much time as most of the functionality has been implemented in the previous step).
-*   Testing the overall working of each and every module of the modified source code with the help of Python Test Suites.
+* Bringing about the decided changes in the Relational Schemas of Systers database.
+* Replacing parts of the above code in their respective places in the Systers source code. (This should not take much time as most of the functionality has been implemented in the previous step).
+* Testing the overall working of each and every module of the modified source code with the help of Python Test Suites.
 
 JULY 6th MID TERM EVALUATION
 
 **July 6 – July 15:**
 
-*   Making further changes in the code to improve the Functionality, Exception handling, Bug Removal.
+* Making further changes in the code to improve the Functionality, Exception handling, Bug Removal.
 
 **July 15 – July 25:**
 
-*   To be in constant touch with the Mailman3's developers and to let them know about our progress.
-*   Most of the time will be consumed for rigorous testing and bug fixes.
+* To be in constant touch with the Mailman3's developers and to let them know about our progress.
+* Most of the time will be consumed for rigorous testing and bug fixes.
 
 **July 25 – July 31:**
 
-*   For Documentation
+* For Documentation
 
 A buffer of two weeks has been kept for any unpredictable delay.
-
-
diff --git a/pages/student/22-proposal_example_2.md b/pages/student/22-proposal_example_2.md
index ca7daabc..469174fc 100644
--- a/pages/student/22-proposal_example_2.md
+++ b/pages/student/22-proposal_example_2.md
@@ -8,7 +8,6 @@ sidebar: student_sidebar
 
 "Reactome-Wikipathways Round-trip Format Converter" by Leontius Adhika Pradhana, GenMAPP, 2010
 
-
 ## Problem description
 
 Reactome is a "free, online, open-source, curated pathway database encompassing many areas of human biology". Each pathway in Reactome is manually curated -- peer-reviewed and cross-referenced with other database -- and thus has great reliability. Another pathway database website WikiPathways, by contrast, lives on the "wiki spirit" allowing anyone to edit and annotate pathways in the website. This makes WikiPathways an ideal venue for staging new pathways to be included in the official Reactome database, as well as a place for the community to review and make changes to pathways which may end up as an official amendment in Reactome.
@@ -17,7 +16,6 @@ However, the two websites use markedly different data structure to store their p
 
 Recent development of Reactome introduced a new proprietary graphical XML format akin to GPML. This XML format adheres to SBGN specification which semantically defines symbols representing biological systems. This project will provide the means to convert to and from GPML and the new Reactome XML format.
 
-
 ## Implementation plan
 
 The project consists of three components:
@@ -40,14 +38,12 @@ A separate script will be made that periodically pulls updates from WikiPathways
 
 The script will also pull updates from Reactome and push new pathways to WikiPathways. Only Reactome pathways that have XML layout will be pushed to WikiPathways.
 
-
 ## Deliverables
 
-*   an XML schema to validate the new Reactome XML format;
-*   a GPML to Reactome XML layout converter and Reactome XML layout to GPML converter, which will be available both as command line tool and a library that can be integrated with WikiPathways infrastructure;
-*   a system using the above converter, integrated to WikiPathways, that will periodically check for updates on both WikiPathways and Reactome and update the websites accordingly;
-*   proper documentation and tests for the above-mentioned components.
-
+* an XML schema to validate the new Reactome XML format;
+* a GPML to Reactome XML layout converter and Reactome XML layout to GPML converter, which will be available both as command line tool and a library that can be integrated with WikiPathways infrastructure;
+* a system using the above converter, integrated to WikiPathways, that will periodically check for updates on both WikiPathways and Reactome and update the websites accordingly;
+* proper documentation and tests for the above-mentioned components.
 
 ## Timeline
 
@@ -88,5 +84,3 @@ Test and document the periodic push/pull mechanism more thoroughly.
 2 -- 16 August
 
 Further refine tests and documentation for the whole project.
-
-
diff --git a/pages/student/23-glossary.md b/pages/student/23-glossary.md
index 4915979c..da33b73f 100644
--- a/pages/student/23-glossary.md
+++ b/pages/student/23-glossary.md
@@ -11,117 +11,94 @@ sidebar: student_sidebar
 
 The shortest way in the geek world to say "I agree with this" or "This is a great idea". It is often used when others have already fleshed out the details and a consensus of how many agree/disagree with the sentiment. It is worth noting to your students if your project uses this as a voting signal so they do not accidentally comment on issues when, as newbies, they should be observing rather than commenting/voting.
 
-
 ## -1
 
 The opposite of +1. Often accompanied by an explanation why, if you are lucky.
 
-
 ## Committer
 
 An individual who has special rights in an open source project. While the scope of this term varies by project, the general idea is that this individual is able to check in source code to the project's main repository.
 
-
 ## Community Bonding Period
 
 The period of time between when accepted students are announced for a particular year of GSoC and the time these students are expected to start coding. This time is an excellent one to introduce students to the community, get them on the right mailing lists, etc. See the "Community Bonding Period" section for more details.
 
-
 ## DVCS
 
 Distributed version control system. A version control system that does not require talking to a centralized server.
 
-
 ## FLOSS
 
 Free/Libre Open Source Software. Likely the most inclusive acronym to describe the software produced for GSoC.
 
-
 ## GSoC
 
 Google Summer of Code
 
-
 ## IDE
 
 Integrated Development Environment
 
-
 ## IM
 
 Instant Messenger
 
-
 ## IRC
 
 Internet Relay Chat
 
-
 ## JFDI
 
 Just Fabulously Do It. Use your imagination. Ask for forgiveness, not for permission. :)
 
-
 ## Lurk
 
 To spend some time watching. Often used in reference to a mailing list where you will read the posts but not make any posts yourself or an IRC channel where you watch how people interact but don't say anything.
 
-
 ## Mentor
 
 Someone who helps a student with their project proposal. See the "How GSoC Works" section for more details.
 
-
 ## Organization
 
 An open source, free software or technology-related project that mentors students for Google Summer of Code. Also known as a mentoring organization.
 
-
 ## Organization Admin (Org Admin)
 
 Cat herders for each open source project participating in the program. Often abbreviated to org admin. See the "How GSoC Works" section for more details.
 
-
 ## Program Administrator
 
 Google employees who run the program. See the "How GSoC Works" section for more details.
 
-
 ## RTFM
 
 **R**ead **T**he **F**LOSS **M**anual ;)
 
-
 ## Secondary Mentor
 
 A person who helps out a student's assigned mentor. At time of writing this manual, the GSoC online system only allows one mentor to be officially assigned to a student proposal, as one person must be responsible for submitting evaluations, etc. However, it is quite common to have multiple mentors for one student.
 
-
 ## SMOP
 
 Simple Matter of Programming
 
-
 ## Summer
 
 Not so much a season as a state of being. While the program is run during the Northern Hemisphere's Spring and Summer, the "Summer" in Google Summer of Code is actually a play on the "Summer of Love".
 
-
 ## TDD
 
 Test Driven Development
 
-
 ## Use Case
 
 A use case describes what a user can do with a particular software system.
 
-
 ## UTC
 
 Coordinated Universal Time
 
-
 ## Waterfall Model
 
 A sequential software development process that usually doesn't work.
diff --git a/third_party/js/jquery.min.js b/third_party/js/jquery.min.js
index fad9ab12..0de648ed 100644
--- a/third_party/js/jquery.min.js
+++ b/third_party/js/jquery.min.js
@@ -1,5 +1,2 @@
-/*! jQuery v2.1.4 | (c) 2005, 2015 jQuery Foundation, Inc. | jquery.org/license */
-!function(a,b){"object"==typeof module&&"object"==typeof module.exports?module.exports=a.document?b(a,!0):function(a){if(!a.document)throw new Error("jQuery requires a window with a document");return b(a)}:b(a)}("undefined"!=typeof window?window:this,function(a,b){var c=[],d=c.slice,e=c.concat,f=c.push,g=c.indexOf,h={},i=h.toString,j=h.hasOwnProperty,k={},l=a.document,m="2.1.4",n=function(a,b){return new n.fn.init(a,b)},o=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,p=/^-ms-/,q=/-([\da-z])/gi,r=function(a,b){return b.toUpperCase()};n.fn=n.prototype={jquery:m,constructor:n,selector:"",length:0,toArray:function(){return d.call(this)},get:function(a){return null!=a?0>a?this[a+this.length]:this[a]:d.call(this)},pushStack:function(a){var b=n.merge(this.constructor(),a);return b.prevObject=this,b.context=this.context,b},each:function(a,b){return n.each(this,a,b)},map:function(a){return this.pushStack(n.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(d.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(0>a?b:0);return this.pushStack(c>=0&&b>c?[this[c]]:[])},end:function(){return this.prevObject||this.constructor(null)},push:f,sort:c.sort,splice:c.splice},n.extend=n.fn.extend=function(){var a,b,c,d,e,f,g=arguments[0]||{},h=1,i=arguments.length,j=!1;for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),"object"==typeof g||n.isFunction(g)||(g={}),h===i&&(g=this,h--);i>h;h++)if(null!=(a=arguments[h]))for(b in a)c=g[b],d=a[b],g!==d&&(j&&d&&(n.isPlainObject(d)||(e=n.isArray(d)))?(e?(e=!1,f=c&&n.isArray(c)?c:[]):f=c&&n.isPlainObject(c)?c:{},g[b]=n.extend(j,f,d)):void 0!==d&&(g[b]=d));return g},n.extend({expando:"jQuery"+(m+Math.random()).replace(/\D/g,""),isReady:!0,error:function(a){throw new Error(a)},noop:function(){},isFunction:function(a){return"function"===n.type(a)},isArray:Array.isArray,isWindow:function(a){return null!=a&&a===a.window},isNumeric:function(a){return!n.isArray(a)&&a-parseFloat(a)+1>=0},isPlainObject:function(a){return"object"!==n.type(a)||a.nodeType||n.isWindow(a)?!1:a.constructor&&!j.call(a.constructor.prototype,"isPrototypeOf")?!1:!0},isEmptyObject:function(a){var b;for(b in a)return!1;return!0},type:function(a){return null==a?a+"":"object"==typeof a||"function"==typeof a?h[i.call(a)]||"object":typeof a},globalEval:function(a){var b,c=eval;a=n.trim(a),a&&(1===a.indexOf("use strict")?(b=l.createElement("script"),b.text=a,l.head.appendChild(b).parentNode.removeChild(b)):c(a))},camelCase:function(a){return a.replace(p,"ms-").replace(q,r)},nodeName:function(a,b){return a.nodeName&&a.nodeName.toLowerCase()===b.toLowerCase()},each:function(a,b,c){var d,e=0,f=a.length,g=s(a);if(c){if(g){for(;f>e;e++)if(d=b.apply(a[e],c),d===!1)break}else for(e in a)if(d=b.apply(a[e],c),d===!1)break}else if(g){for(;f>e;e++)if(d=b.call(a[e],e,a[e]),d===!1)break}else for(e in a)if(d=b.call(a[e],e,a[e]),d===!1)break;return a},trim:function(a){return null==a?"":(a+"").replace(o,"")},makeArray:function(a,b){var c=b||[];return null!=a&&(s(Object(a))?n.merge(c,"string"==typeof a?[a]:a):f.call(c,a)),c},inArray:function(a,b,c){return null==b?-1:g.call(b,a,c)},merge:function(a,b){for(var c=+b.length,d=0,e=a.length;c>d;d++)a[e++]=b[d];return a.length=e,a},grep:function(a,b,c){for(var d,e=[],f=0,g=a.length,h=!c;g>f;f++)d=!b(a[f],f),d!==h&&e.push(a[f]);return e},map:function(a,b,c){var d,f=0,g=a.length,h=s(a),i=[];if(h)for(;g>f;f++)d=b(a[f],f,c),null!=d&&i.push(d);else for(f in a)d=b(a[f],f,c),null!=d&&i.push(d);return e.apply([],i)},guid:1,proxy:function(a,b){var c,e,f;return"string"==typeof b&&(c=a[b],b=a,a=c),n.isFunction(a)?(e=d.call(arguments,2),f=function(){return a.apply(b||this,e.concat(d.call(arguments)))},f.guid=a.guid=a.guid||n.guid++,f):void 0},now:Date.now,support:k}),n.each("Boolean Number String Function Array Date RegExp Object Error".split(" "),function(a,b){h["[object "+b+"]"]=b.toLowerCase()});function s(a){var b="length"in a&&a.length,c=n.type(a);return"function"===c||n.isWindow(a)?!1:1===a.nodeType&&b?!0:"array"===c||0===b||"number"==typeof b&&b>0&&b-1 in a}var t=function(a){var b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u="sizzle"+1*new Date,v=a.document,w=0,x=0,y=ha(),z=ha(),A=ha(),B=function(a,b){return a===b&&(l=!0),0},C=1<<31,D={}.hasOwnProperty,E=[],F=E.pop,G=E.push,H=E.push,I=E.slice,J=function(a,b){for(var c=0,d=a.length;d>c;c++)if(a[c]===b)return c;return-1},K="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",L="[\\x20\\t\\r\\n\\f]",M="(?:\\\\.|[\\w-]|[^\\x00-\\xa0])+",N=M.replace("w","w#"),O="\\["+L+"*("+M+")(?:"+L+"*([*^$|!~]?=)"+L+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+N+"))|)"+L+"*\\]",P=":("+M+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+O+")*)|.*)\\)|)",Q=new RegExp(L+"+","g"),R=new RegExp("^"+L+"+|((?:^|[^\\\\])(?:\\\\.)*)"+L+"+$","g"),S=new RegExp("^"+L+"*,"+L+"*"),T=new RegExp("^"+L+"*([>+~]|"+L+")"+L+"*"),U=new RegExp("="+L+"*([^\\]'\"]*?)"+L+"*\\]","g"),V=new RegExp(P),W=new RegExp("^"+N+"$"),X={ID:new RegExp("^#("+M+")"),CLASS:new RegExp("^\\.("+M+")"),TAG:new RegExp("^("+M.replace("w","w*")+")"),ATTR:new RegExp("^"+O),PSEUDO:new RegExp("^"+P),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+L+"*(even|odd|(([+-]|)(\\d*)n|)"+L+"*(?:([+-]|)"+L+"*(\\d+)|))"+L+"*\\)|)","i"),bool:new RegExp("^(?:"+K+")$","i"),needsContext:new RegExp("^"+L+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+L+"*((?:-\\d)?\\d*)"+L+"*\\)|)(?=[^-]|$)","i")},Y=/^(?:input|select|textarea|button)$/i,Z=/^h\d$/i,$=/^[^{]+\{\s*\[native \w/,_=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,aa=/[+~]/,ba=/'|\\/g,ca=new RegExp("\\\\([\\da-f]{1,6}"+L+"?|("+L+")|.)","ig"),da=function(a,b,c){var d="0x"+b-65536;return d!==d||c?b:0>d?String.fromCharCode(d+65536):String.fromCharCode(d>>10|55296,1023&d|56320)},ea=function(){m()};try{H.apply(E=I.call(v.childNodes),v.childNodes),E[v.childNodes.length].nodeType}catch(fa){H={apply:E.length?function(a,b){G.apply(a,I.call(b))}:function(a,b){var c=a.length,d=0;while(a[c++]=b[d++]);a.length=c-1}}}function ga(a,b,d,e){var f,h,j,k,l,o,r,s,w,x;if((b?b.ownerDocument||b:v)!==n&&m(b),b=b||n,d=d||[],k=b.nodeType,"string"!=typeof a||!a||1!==k&&9!==k&&11!==k)return d;if(!e&&p){if(11!==k&&(f=_.exec(a)))if(j=f[1]){if(9===k){if(h=b.getElementById(j),!h||!h.parentNode)return d;if(h.id===j)return d.push(h),d}else if(b.ownerDocument&&(h=b.ownerDocument.getElementById(j))&&t(b,h)&&h.id===j)return d.push(h),d}else{if(f[2])return H.apply(d,b.getElementsByTagName(a)),d;if((j=f[3])&&c.getElementsByClassName)return H.apply(d,b.getElementsByClassName(j)),d}if(c.qsa&&(!q||!q.test(a))){if(s=r=u,w=b,x=1!==k&&a,1===k&&"object"!==b.nodeName.toLowerCase()){o=g(a),(r=b.getAttribute("id"))?s=r.replace(ba,"\\$&"):b.setAttribute("id",s),s="[id='"+s+"'] ",l=o.length;while(l--)o[l]=s+ra(o[l]);w=aa.test(a)&&pa(b.parentNode)||b,x=o.join(",")}if(x)try{return H.apply(d,w.querySelectorAll(x)),d}catch(y){}finally{r||b.removeAttribute("id")}}}return i(a.replace(R,"$1"),b,d,e)}function ha(){var a=[];function b(c,e){return a.push(c+" ")>d.cacheLength&&delete b[a.shift()],b[c+" "]=e}return b}function ia(a){return a[u]=!0,a}function ja(a){var b=n.createElement("div");try{return!!a(b)}catch(c){return!1}finally{b.parentNode&&b.parentNode.removeChild(b),b=null}}function ka(a,b){var c=a.split("|"),e=a.length;while(e--)d.attrHandle[c[e]]=b}function la(a,b){var c=b&&a,d=c&&1===a.nodeType&&1===b.nodeType&&(~b.sourceIndex||C)-(~a.sourceIndex||C);if(d)return d;if(c)while(c=c.nextSibling)if(c===b)return-1;return a?1:-1}function ma(a){return function(b){var c=b.nodeName.toLowerCase();return"input"===c&&b.type===a}}function na(a){return function(b){var c=b.nodeName.toLowerCase();return("input"===c||"button"===c)&&b.type===a}}function oa(a){return ia(function(b){return b=+b,ia(function(c,d){var e,f=a([],c.length,b),g=f.length;while(g--)c[e=f[g]]&&(c[e]=!(d[e]=c[e]))})})}function pa(a){return a&&"undefined"!=typeof a.getElementsByTagName&&a}c=ga.support={},f=ga.isXML=function(a){var b=a&&(a.ownerDocument||a).documentElement;return b?"HTML"!==b.nodeName:!1},m=ga.setDocument=function(a){var b,e,g=a?a.ownerDocument||a:v;return g!==n&&9===g.nodeType&&g.documentElement?(n=g,o=g.documentElement,e=g.defaultView,e&&e!==e.top&&(e.addEventListener?e.addEventListener("unload",ea,!1):e.attachEvent&&e.attachEvent("onunload",ea)),p=!f(g),c.attributes=ja(function(a){return a.className="i",!a.getAttribute("className")}),c.getElementsByTagName=ja(function(a){return a.appendChild(g.createComment("")),!a.getElementsByTagName("*").length}),c.getElementsByClassName=$.test(g.getElementsByClassName),c.getById=ja(function(a){return o.appendChild(a).id=u,!g.getElementsByName||!g.getElementsByName(u).length}),c.getById?(d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c=b.getElementById(a);return c&&c.parentNode?[c]:[]}},d.filter.ID=function(a){var b=a.replace(ca,da);return function(a){return a.getAttribute("id")===b}}):(delete d.find.ID,d.filter.ID=function(a){var b=a.replace(ca,da);return function(a){var c="undefined"!=typeof a.getAttributeNode&&a.getAttributeNode("id");return c&&c.value===b}}),d.find.TAG=c.getElementsByTagName?function(a,b){return"undefined"!=typeof b.getElementsByTagName?b.getElementsByTagName(a):c.qsa?b.querySelectorAll(a):void 0}:function(a,b){var c,d=[],e=0,f=b.getElementsByTagName(a);if("*"===a){while(c=f[e++])1===c.nodeType&&d.push(c);return d}return f},d.find.CLASS=c.getElementsByClassName&&function(a,b){return p?b.getElementsByClassName(a):void 0},r=[],q=[],(c.qsa=$.test(g.querySelectorAll))&&(ja(function(a){o.appendChild(a).innerHTML="<a id='"+u+"'></a><select id='"+u+"-\f]' msallowcapture=''><option selected=''></option></select>",a.querySelectorAll("[msallowcapture^='']").length&&q.push("[*^$]="+L+"*(?:''|\"\")"),a.querySelectorAll("[selected]").length||q.push("\\["+L+"*(?:value|"+K+")"),a.querySelectorAll("[id~="+u+"-]").length||q.push("~="),a.querySelectorAll(":checked").length||q.push(":checked"),a.querySelectorAll("a#"+u+"+*").length||q.push(".#.+[+~]")}),ja(function(a){var b=g.createElement("input");b.setAttribute("type","hidden"),a.appendChild(b).setAttribute("name","D"),a.querySelectorAll("[name=d]").length&&q.push("name"+L+"*[*^$|!~]?="),a.querySelectorAll(":enabled").length||q.push(":enabled",":disabled"),a.querySelectorAll("*,:x"),q.push(",.*:")})),(c.matchesSelector=$.test(s=o.matches||o.webkitMatchesSelector||o.mozMatchesSelector||o.oMatchesSelector||o.msMatchesSelector))&&ja(function(a){c.disconnectedMatch=s.call(a,"div"),s.call(a,"[s!='']:x"),r.push("!=",P)}),q=q.length&&new RegExp(q.join("|")),r=r.length&&new RegExp(r.join("|")),b=$.test(o.compareDocumentPosition),t=b||$.test(o.contains)?function(a,b){var c=9===a.nodeType?a.documentElement:a,d=b&&b.parentNode;return a===d||!(!d||1!==d.nodeType||!(c.contains?c.contains(d):a.compareDocumentPosition&&16&a.compareDocumentPosition(d)))}:function(a,b){if(b)while(b=b.parentNode)if(b===a)return!0;return!1},B=b?function(a,b){if(a===b)return l=!0,0;var d=!a.compareDocumentPosition-!b.compareDocumentPosition;return d?d:(d=(a.ownerDocument||a)===(b.ownerDocument||b)?a.compareDocumentPosition(b):1,1&d||!c.sortDetached&&b.compareDocumentPosition(a)===d?a===g||a.ownerDocument===v&&t(v,a)?-1:b===g||b.ownerDocument===v&&t(v,b)?1:k?J(k,a)-J(k,b):0:4&d?-1:1)}:function(a,b){if(a===b)return l=!0,0;var c,d=0,e=a.parentNode,f=b.parentNode,h=[a],i=[b];if(!e||!f)return a===g?-1:b===g?1:e?-1:f?1:k?J(k,a)-J(k,b):0;if(e===f)return la(a,b);c=a;while(c=c.parentNode)h.unshift(c);c=b;while(c=c.parentNode)i.unshift(c);while(h[d]===i[d])d++;return d?la(h[d],i[d]):h[d]===v?-1:i[d]===v?1:0},g):n},ga.matches=function(a,b){return ga(a,null,null,b)},ga.matchesSelector=function(a,b){if((a.ownerDocument||a)!==n&&m(a),b=b.replace(U,"='$1']"),!(!c.matchesSelector||!p||r&&r.test(b)||q&&q.test(b)))try{var d=s.call(a,b);if(d||c.disconnectedMatch||a.document&&11!==a.document.nodeType)return d}catch(e){}return ga(b,n,null,[a]).length>0},ga.contains=function(a,b){return(a.ownerDocument||a)!==n&&m(a),t(a,b)},ga.attr=function(a,b){(a.ownerDocument||a)!==n&&m(a);var e=d.attrHandle[b.toLowerCase()],f=e&&D.call(d.attrHandle,b.toLowerCase())?e(a,b,!p):void 0;return void 0!==f?f:c.attributes||!p?a.getAttribute(b):(f=a.getAttributeNode(b))&&f.specified?f.value:null},ga.error=function(a){throw new Error("Syntax error, unrecognized expression: "+a)},ga.uniqueSort=function(a){var b,d=[],e=0,f=0;if(l=!c.detectDuplicates,k=!c.sortStable&&a.slice(0),a.sort(B),l){while(b=a[f++])b===a[f]&&(e=d.push(f));while(e--)a.splice(d[e],1)}return k=null,a},e=ga.getText=function(a){var b,c="",d=0,f=a.nodeType;if(f){if(1===f||9===f||11===f){if("string"==typeof a.textContent)return a.textContent;for(a=a.firstChild;a;a=a.nextSibling)c+=e(a)}else if(3===f||4===f)return a.nodeValue}else while(b=a[d++])c+=e(b);return c},d=ga.selectors={cacheLength:50,createPseudo:ia,match:X,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(a){return a[1]=a[1].replace(ca,da),a[3]=(a[3]||a[4]||a[5]||"").replace(ca,da),"~="===a[2]&&(a[3]=" "+a[3]+" "),a.slice(0,4)},CHILD:function(a){return a[1]=a[1].toLowerCase(),"nth"===a[1].slice(0,3)?(a[3]||ga.error(a[0]),a[4]=+(a[4]?a[5]+(a[6]||1):2*("even"===a[3]||"odd"===a[3])),a[5]=+(a[7]+a[8]||"odd"===a[3])):a[3]&&ga.error(a[0]),a},PSEUDO:function(a){var b,c=!a[6]&&a[2];return X.CHILD.test(a[0])?null:(a[3]?a[2]=a[4]||a[5]||"":c&&V.test(c)&&(b=g(c,!0))&&(b=c.indexOf(")",c.length-b)-c.length)&&(a[0]=a[0].slice(0,b),a[2]=c.slice(0,b)),a.slice(0,3))}},filter:{TAG:function(a){var b=a.replace(ca,da).toLowerCase();return"*"===a?function(){return!0}:function(a){return a.nodeName&&a.nodeName.toLowerCase()===b}},CLASS:function(a){var b=y[a+" "];return b||(b=new RegExp("(^|"+L+")"+a+"("+L+"|$)"))&&y(a,function(a){return b.test("string"==typeof a.className&&a.className||"undefined"!=typeof a.getAttribute&&a.getAttribute("class")||"")})},ATTR:function(a,b,c){return function(d){var e=ga.attr(d,a);return null==e?"!="===b:b?(e+="","="===b?e===c:"!="===b?e!==c:"^="===b?c&&0===e.indexOf(c):"*="===b?c&&e.indexOf(c)>-1:"$="===b?c&&e.slice(-c.length)===c:"~="===b?(" "+e.replace(Q," ")+" ").indexOf(c)>-1:"|="===b?e===c||e.slice(0,c.length+1)===c+"-":!1):!0}},CHILD:function(a,b,c,d,e){var f="nth"!==a.slice(0,3),g="last"!==a.slice(-4),h="of-type"===b;return 1===d&&0===e?function(a){return!!a.parentNode}:function(b,c,i){var j,k,l,m,n,o,p=f!==g?"nextSibling":"previousSibling",q=b.parentNode,r=h&&b.nodeName.toLowerCase(),s=!i&&!h;if(q){if(f){while(p){l=b;while(l=l[p])if(h?l.nodeName.toLowerCase()===r:1===l.nodeType)return!1;o=p="only"===a&&!o&&"nextSibling"}return!0}if(o=[g?q.firstChild:q.lastChild],g&&s){k=q[u]||(q[u]={}),j=k[a]||[],n=j[0]===w&&j[1],m=j[0]===w&&j[2],l=n&&q.childNodes[n];while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if(1===l.nodeType&&++m&&l===b){k[a]=[w,n,m];break}}else if(s&&(j=(b[u]||(b[u]={}))[a])&&j[0]===w)m=j[1];else while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if((h?l.nodeName.toLowerCase()===r:1===l.nodeType)&&++m&&(s&&((l[u]||(l[u]={}))[a]=[w,m]),l===b))break;return m-=e,m===d||m%d===0&&m/d>=0}}},PSEUDO:function(a,b){var c,e=d.pseudos[a]||d.setFilters[a.toLowerCase()]||ga.error("unsupported pseudo: "+a);return e[u]?e(b):e.length>1?(c=[a,a,"",b],d.setFilters.hasOwnProperty(a.toLowerCase())?ia(function(a,c){var d,f=e(a,b),g=f.length;while(g--)d=J(a,f[g]),a[d]=!(c[d]=f[g])}):function(a){return e(a,0,c)}):e}},pseudos:{not:ia(function(a){var b=[],c=[],d=h(a.replace(R,"$1"));return d[u]?ia(function(a,b,c,e){var f,g=d(a,null,e,[]),h=a.length;while(h--)(f=g[h])&&(a[h]=!(b[h]=f))}):function(a,e,f){return b[0]=a,d(b,null,f,c),b[0]=null,!c.pop()}}),has:ia(function(a){return function(b){return ga(a,b).length>0}}),contains:ia(function(a){return a=a.replace(ca,da),function(b){return(b.textContent||b.innerText||e(b)).indexOf(a)>-1}}),lang:ia(function(a){return W.test(a||"")||ga.error("unsupported lang: "+a),a=a.replace(ca,da).toLowerCase(),function(b){var c;do if(c=p?b.lang:b.getAttribute("xml:lang")||b.getAttribute("lang"))return c=c.toLowerCase(),c===a||0===c.indexOf(a+"-");while((b=b.parentNode)&&1===b.nodeType);return!1}}),target:function(b){var c=a.location&&a.location.hash;return c&&c.slice(1)===b.id},root:function(a){return a===o},focus:function(a){return a===n.activeElement&&(!n.hasFocus||n.hasFocus())&&!!(a.type||a.href||~a.tabIndex)},enabled:function(a){return a.disabled===!1},disabled:function(a){return a.disabled===!0},checked:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&!!a.checked||"option"===b&&!!a.selected},selected:function(a){return a.parentNode&&a.parentNode.selectedIndex,a.selected===!0},empty:function(a){for(a=a.firstChild;a;a=a.nextSibling)if(a.nodeType<6)return!1;return!0},parent:function(a){return!d.pseudos.empty(a)},header:function(a){return Z.test(a.nodeName)},input:function(a){return Y.test(a.nodeName)},button:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&"button"===a.type||"button"===b},text:function(a){var b;return"input"===a.nodeName.toLowerCase()&&"text"===a.type&&(null==(b=a.getAttribute("type"))||"text"===b.toLowerCase())},first:oa(function(){return[0]}),last:oa(function(a,b){return[b-1]}),eq:oa(function(a,b,c){return[0>c?c+b:c]}),even:oa(function(a,b){for(var c=0;b>c;c+=2)a.push(c);return a}),odd:oa(function(a,b){for(var c=1;b>c;c+=2)a.push(c);return a}),lt:oa(function(a,b,c){for(var d=0>c?c+b:c;--d>=0;)a.push(d);return a}),gt:oa(function(a,b,c){for(var d=0>c?c+b:c;++d<b;)a.push(d);return a})}},d.pseudos.nth=d.pseudos.eq;for(b in{radio:!0,checkbox:!0,file:!0,password:!0,image:!0})d.pseudos[b]=ma(b);for(b in{submit:!0,reset:!0})d.pseudos[b]=na(b);function qa(){}qa.prototype=d.filters=d.pseudos,d.setFilters=new qa,g=ga.tokenize=function(a,b){var c,e,f,g,h,i,j,k=z[a+" "];if(k)return b?0:k.slice(0);h=a,i=[],j=d.preFilter;while(h){(!c||(e=S.exec(h)))&&(e&&(h=h.slice(e[0].length)||h),i.push(f=[])),c=!1,(e=T.exec(h))&&(c=e.shift(),f.push({value:c,type:e[0].replace(R," ")}),h=h.slice(c.length));for(g in d.filter)!(e=X[g].exec(h))||j[g]&&!(e=j[g](e))||(c=e.shift(),f.push({value:c,type:g,matches:e}),h=h.slice(c.length));if(!c)break}return b?h.length:h?ga.error(a):z(a,i).slice(0)};function ra(a){for(var b=0,c=a.length,d="";c>b;b++)d+=a[b].value;return d}function sa(a,b,c){var d=b.dir,e=c&&"parentNode"===d,f=x++;return b.first?function(b,c,f){while(b=b[d])if(1===b.nodeType||e)return a(b,c,f)}:function(b,c,g){var h,i,j=[w,f];if(g){while(b=b[d])if((1===b.nodeType||e)&&a(b,c,g))return!0}else while(b=b[d])if(1===b.nodeType||e){if(i=b[u]||(b[u]={}),(h=i[d])&&h[0]===w&&h[1]===f)return j[2]=h[2];if(i[d]=j,j[2]=a(b,c,g))return!0}}}function ta(a){return a.length>1?function(b,c,d){var e=a.length;while(e--)if(!a[e](b,c,d))return!1;return!0}:a[0]}function ua(a,b,c){for(var d=0,e=b.length;e>d;d++)ga(a,b[d],c);return c}function va(a,b,c,d,e){for(var f,g=[],h=0,i=a.length,j=null!=b;i>h;h++)(f=a[h])&&(!c||c(f,d,e))&&(g.push(f),j&&b.push(h));return g}function wa(a,b,c,d,e,f){return d&&!d[u]&&(d=wa(d)),e&&!e[u]&&(e=wa(e,f)),ia(function(f,g,h,i){var j,k,l,m=[],n=[],o=g.length,p=f||ua(b||"*",h.nodeType?[h]:h,[]),q=!a||!f&&b?p:va(p,m,a,h,i),r=c?e||(f?a:o||d)?[]:g:q;if(c&&c(q,r,h,i),d){j=va(r,n),d(j,[],h,i),k=j.length;while(k--)(l=j[k])&&(r[n[k]]=!(q[n[k]]=l))}if(f){if(e||a){if(e){j=[],k=r.length;while(k--)(l=r[k])&&j.push(q[k]=l);e(null,r=[],j,i)}k=r.length;while(k--)(l=r[k])&&(j=e?J(f,l):m[k])>-1&&(f[j]=!(g[j]=l))}}else r=va(r===g?r.splice(o,r.length):r),e?e(null,g,r,i):H.apply(g,r)})}function xa(a){for(var b,c,e,f=a.length,g=d.relative[a[0].type],h=g||d.relative[" "],i=g?1:0,k=sa(function(a){return a===b},h,!0),l=sa(function(a){return J(b,a)>-1},h,!0),m=[function(a,c,d){var e=!g&&(d||c!==j)||((b=c).nodeType?k(a,c,d):l(a,c,d));return b=null,e}];f>i;i++)if(c=d.relative[a[i].type])m=[sa(ta(m),c)];else{if(c=d.filter[a[i].type].apply(null,a[i].matches),c[u]){for(e=++i;f>e;e++)if(d.relative[a[e].type])break;return wa(i>1&&ta(m),i>1&&ra(a.slice(0,i-1).concat({value:" "===a[i-2].type?"*":""})).replace(R,"$1"),c,e>i&&xa(a.slice(i,e)),f>e&&xa(a=a.slice(e)),f>e&&ra(a))}m.push(c)}return ta(m)}function ya(a,b){var c=b.length>0,e=a.length>0,f=function(f,g,h,i,k){var l,m,o,p=0,q="0",r=f&&[],s=[],t=j,u=f||e&&d.find.TAG("*",k),v=w+=null==t?1:Math.random()||.1,x=u.length;for(k&&(j=g!==n&&g);q!==x&&null!=(l=u[q]);q++){if(e&&l){m=0;while(o=a[m++])if(o(l,g,h)){i.push(l);break}k&&(w=v)}c&&((l=!o&&l)&&p--,f&&r.push(l))}if(p+=q,c&&q!==p){m=0;while(o=b[m++])o(r,s,g,h);if(f){if(p>0)while(q--)r[q]||s[q]||(s[q]=F.call(i));s=va(s)}H.apply(i,s),k&&!f&&s.length>0&&p+b.length>1&&ga.uniqueSort(i)}return k&&(w=v,j=t),r};return c?ia(f):f}return h=ga.compile=function(a,b){var c,d=[],e=[],f=A[a+" "];if(!f){b||(b=g(a)),c=b.length;while(c--)f=xa(b[c]),f[u]?d.push(f):e.push(f);f=A(a,ya(e,d)),f.selector=a}return f},i=ga.select=function(a,b,e,f){var i,j,k,l,m,n="function"==typeof a&&a,o=!f&&g(a=n.selector||a);if(e=e||[],1===o.length){if(j=o[0]=o[0].slice(0),j.length>2&&"ID"===(k=j[0]).type&&c.getById&&9===b.nodeType&&p&&d.relative[j[1].type]){if(b=(d.find.ID(k.matches[0].replace(ca,da),b)||[])[0],!b)return e;n&&(b=b.parentNode),a=a.slice(j.shift().value.length)}i=X.needsContext.test(a)?0:j.length;while(i--){if(k=j[i],d.relative[l=k.type])break;if((m=d.find[l])&&(f=m(k.matches[0].replace(ca,da),aa.test(j[0].type)&&pa(b.parentNode)||b))){if(j.splice(i,1),a=f.length&&ra(j),!a)return H.apply(e,f),e;break}}}return(n||h(a,o))(f,b,!p,e,aa.test(a)&&pa(b.parentNode)||b),e},c.sortStable=u.split("").sort(B).join("")===u,c.detectDuplicates=!!l,m(),c.sortDetached=ja(function(a){return 1&a.compareDocumentPosition(n.createElement("div"))}),ja(function(a){return a.innerHTML="<a href='#'></a>","#"===a.firstChild.getAttribute("href")})||ka("type|href|height|width",function(a,b,c){return c?void 0:a.getAttribute(b,"type"===b.toLowerCase()?1:2)}),c.attributes&&ja(function(a){return a.innerHTML="<input/>",a.firstChild.setAttribute("value",""),""===a.firstChild.getAttribute("value")})||ka("value",function(a,b,c){return c||"input"!==a.nodeName.toLowerCase()?void 0:a.defaultValue}),ja(function(a){return null==a.getAttribute("disabled")})||ka(K,function(a,b,c){var d;return c?void 0:a[b]===!0?b.toLowerCase():(d=a.getAttributeNode(b))&&d.specified?d.value:null}),ga}(a);n.find=t,n.expr=t.selectors,n.expr[":"]=n.expr.pseudos,n.unique=t.uniqueSort,n.text=t.getText,n.isXMLDoc=t.isXML,n.contains=t.contains;var u=n.expr.match.needsContext,v=/^<(\w+)\s*\/?>(?:<\/\1>|)$/,w=/^.[^:#\[\.,]*$/;function x(a,b,c){if(n.isFunction(b))return n.grep(a,function(a,d){return!!b.call(a,d,a)!==c});if(b.nodeType)return n.grep(a,function(a){return a===b!==c});if("string"==typeof b){if(w.test(b))return n.filter(b,a,c);b=n.filter(b,a)}return n.grep(a,function(a){return g.call(b,a)>=0!==c})}n.filter=function(a,b,c){var d=b[0];return c&&(a=":not("+a+")"),1===b.length&&1===d.nodeType?n.find.matchesSelector(d,a)?[d]:[]:n.find.matches(a,n.grep(b,function(a){return 1===a.nodeType}))},n.fn.extend({find:function(a){var b,c=this.length,d=[],e=this;if("string"!=typeof a)return this.pushStack(n(a).filter(function(){for(b=0;c>b;b++)if(n.contains(e[b],this))return!0}));for(b=0;c>b;b++)n.find(a,e[b],d);return d=this.pushStack(c>1?n.unique(d):d),d.selector=this.selector?this.selector+" "+a:a,d},filter:function(a){return this.pushStack(x(this,a||[],!1))},not:function(a){return this.pushStack(x(this,a||[],!0))},is:function(a){return!!x(this,"string"==typeof a&&u.test(a)?n(a):a||[],!1).length}});var y,z=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/,A=n.fn.init=function(a,b){var c,d;if(!a)return this;if("string"==typeof a){if(c="<"===a[0]&&">"===a[a.length-1]&&a.length>=3?[null,a,null]:z.exec(a),!c||!c[1]&&b)return!b||b.jquery?(b||y).find(a):this.constructor(b).find(a);if(c[1]){if(b=b instanceof n?b[0]:b,n.merge(this,n.parseHTML(c[1],b&&b.nodeType?b.ownerDocument||b:l,!0)),v.test(c[1])&&n.isPlainObject(b))for(c in b)n.isFunction(this[c])?this[c](b[c]):this.attr(c,b[c]);return this}return d=l.getElementById(c[2]),d&&d.parentNode&&(this.length=1,this[0]=d),this.context=l,this.selector=a,this}return a.nodeType?(this.context=this[0]=a,this.length=1,this):n.isFunction(a)?"undefined"!=typeof y.ready?y.ready(a):a(n):(void 0!==a.selector&&(this.selector=a.selector,this.context=a.context),n.makeArray(a,this))};A.prototype=n.fn,y=n(l);var B=/^(?:parents|prev(?:Until|All))/,C={children:!0,contents:!0,next:!0,prev:!0};n.extend({dir:function(a,b,c){var d=[],e=void 0!==c;while((a=a[b])&&9!==a.nodeType)if(1===a.nodeType){if(e&&n(a).is(c))break;d.push(a)}return d},sibling:function(a,b){for(var c=[];a;a=a.nextSibling)1===a.nodeType&&a!==b&&c.push(a);return c}}),n.fn.extend({has:function(a){var b=n(a,this),c=b.length;return this.filter(function(){for(var a=0;c>a;a++)if(n.contains(this,b[a]))return!0})},closest:function(a,b){for(var c,d=0,e=this.length,f=[],g=u.test(a)||"string"!=typeof a?n(a,b||this.context):0;e>d;d++)for(c=this[d];c&&c!==b;c=c.parentNode)if(c.nodeType<11&&(g?g.index(c)>-1:1===c.nodeType&&n.find.matchesSelector(c,a))){f.push(c);break}return this.pushStack(f.length>1?n.unique(f):f)},index:function(a){return a?"string"==typeof a?g.call(n(a),this[0]):g.call(this,a.jquery?a[0]:a):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(a,b){return this.pushStack(n.unique(n.merge(this.get(),n(a,b))))},addBack:function(a){return this.add(null==a?this.prevObject:this.prevObject.filter(a))}});function D(a,b){while((a=a[b])&&1!==a.nodeType);return a}n.each({parent:function(a){var b=a.parentNode;return b&&11!==b.nodeType?b:null},parents:function(a){return n.dir(a,"parentNode")},parentsUntil:function(a,b,c){return n.dir(a,"parentNode",c)},next:function(a){return D(a,"nextSibling")},prev:function(a){return D(a,"previousSibling")},nextAll:function(a){return n.dir(a,"nextSibling")},prevAll:function(a){return n.dir(a,"previousSibling")},nextUntil:function(a,b,c){return n.dir(a,"nextSibling",c)},prevUntil:function(a,b,c){return n.dir(a,"previousSibling",c)},siblings:function(a){return n.sibling((a.parentNode||{}).firstChild,a)},children:function(a){return n.sibling(a.firstChild)},contents:function(a){return a.contentDocument||n.merge([],a.childNodes)}},function(a,b){n.fn[a]=function(c,d){var e=n.map(this,b,c);return"Until"!==a.slice(-5)&&(d=c),d&&"string"==typeof d&&(e=n.filter(d,e)),this.length>1&&(C[a]||n.unique(e),B.test(a)&&e.reverse()),this.pushStack(e)}});var E=/\S+/g,F={};function G(a){var b=F[a]={};return n.each(a.match(E)||[],function(a,c){b[c]=!0}),b}n.Callbacks=function(a){a="string"==typeof a?F[a]||G(a):n.extend({},a);var b,c,d,e,f,g,h=[],i=!a.once&&[],j=function(l){for(b=a.memory&&l,c=!0,g=e||0,e=0,f=h.length,d=!0;h&&f>g;g++)if(h[g].apply(l[0],l[1])===!1&&a.stopOnFalse){b=!1;break}d=!1,h&&(i?i.length&&j(i.shift()):b?h=[]:k.disable())},k={add:function(){if(h){var c=h.length;!function g(b){n.each(b,function(b,c){var d=n.type(c);"function"===d?a.unique&&k.has(c)||h.push(c):c&&c.length&&"string"!==d&&g(c)})}(arguments),d?f=h.length:b&&(e=c,j(b))}return this},remove:function(){return h&&n.each(arguments,function(a,b){var c;while((c=n.inArray(b,h,c))>-1)h.splice(c,1),d&&(f>=c&&f--,g>=c&&g--)}),this},has:function(a){return a?n.inArray(a,h)>-1:!(!h||!h.length)},empty:function(){return h=[],f=0,this},disable:function(){return h=i=b=void 0,this},disabled:function(){return!h},lock:function(){return i=void 0,b||k.disable(),this},locked:function(){return!i},fireWith:function(a,b){return!h||c&&!i||(b=b||[],b=[a,b.slice?b.slice():b],d?i.push(b):j(b)),this},fire:function(){return k.fireWith(this,arguments),this},fired:function(){return!!c}};return k},n.extend({Deferred:function(a){var b=[["resolve","done",n.Callbacks("once memory"),"resolved"],["reject","fail",n.Callbacks("once memory"),"rejected"],["notify","progress",n.Callbacks("memory")]],c="pending",d={state:function(){return c},always:function(){return e.done(arguments).fail(arguments),this},then:function(){var a=arguments;return n.Deferred(function(c){n.each(b,function(b,f){var g=n.isFunction(a[b])&&a[b];e[f[1]](function(){var a=g&&g.apply(this,arguments);a&&n.isFunction(a.promise)?a.promise().done(c.resolve).fail(c.reject).progress(c.notify):c[f[0]+"With"](this===d?c.promise():this,g?[a]:arguments)})}),a=null}).promise()},promise:function(a){return null!=a?n.extend(a,d):d}},e={};return d.pipe=d.then,n.each(b,function(a,f){var g=f[2],h=f[3];d[f[1]]=g.add,h&&g.add(function(){c=h},b[1^a][2].disable,b[2][2].lock),e[f[0]]=function(){return e[f[0]+"With"](this===e?d:this,arguments),this},e[f[0]+"With"]=g.fireWith}),d.promise(e),a&&a.call(e,e),e},when:function(a){var b=0,c=d.call(arguments),e=c.length,f=1!==e||a&&n.isFunction(a.promise)?e:0,g=1===f?a:n.Deferred(),h=function(a,b,c){return function(e){b[a]=this,c[a]=arguments.length>1?d.call(arguments):e,c===i?g.notifyWith(b,c):--f||g.resolveWith(b,c)}},i,j,k;if(e>1)for(i=new Array(e),j=new Array(e),k=new Array(e);e>b;b++)c[b]&&n.isFunction(c[b].promise)?c[b].promise().done(h(b,k,c)).fail(g.reject).progress(h(b,j,i)):--f;return f||g.resolveWith(k,c),g.promise()}});var H;n.fn.ready=function(a){return n.ready.promise().done(a),this},n.extend({isReady:!1,readyWait:1,holdReady:function(a){a?n.readyWait++:n.ready(!0)},ready:function(a){(a===!0?--n.readyWait:n.isReady)||(n.isReady=!0,a!==!0&&--n.readyWait>0||(H.resolveWith(l,[n]),n.fn.triggerHandler&&(n(l).triggerHandler("ready"),n(l).off("ready"))))}});function I(){l.removeEventListener("DOMContentLoaded",I,!1),a.removeEventListener("load",I,!1),n.ready()}n.ready.promise=function(b){return H||(H=n.Deferred(),"complete"===l.readyState?setTimeout(n.ready):(l.addEventListener("DOMContentLoaded",I,!1),a.addEventListener("load",I,!1))),H.promise(b)},n.ready.promise();var J=n.access=function(a,b,c,d,e,f,g){var h=0,i=a.length,j=null==c;if("object"===n.type(c)){e=!0;for(h in c)n.access(a,b,h,c[h],!0,f,g)}else if(void 0!==d&&(e=!0,n.isFunction(d)||(g=!0),j&&(g?(b.call(a,d),b=null):(j=b,b=function(a,b,c){return j.call(n(a),c)})),b))for(;i>h;h++)b(a[h],c,g?d:d.call(a[h],h,b(a[h],c)));return e?a:j?b.call(a):i?b(a[0],c):f};n.acceptData=function(a){return 1===a.nodeType||9===a.nodeType||!+a.nodeType};function K(){Object.defineProperty(this.cache={},0,{get:function(){return{}}}),this.expando=n.expando+K.uid++}K.uid=1,K.accepts=n.acceptData,K.prototype={key:function(a){if(!K.accepts(a))return 0;var b={},c=a[this.expando];if(!c){c=K.uid++;try{b[this.expando]={value:c},Object.defineProperties(a,b)}catch(d){b[this.expando]=c,n.extend(a,b)}}return this.cache[c]||(this.cache[c]={}),c},set:function(a,b,c){var d,e=this.key(a),f=this.cache[e];if("string"==typeof b)f[b]=c;else if(n.isEmptyObject(f))n.extend(this.cache[e],b);else for(d in b)f[d]=b[d];return f},get:function(a,b){var c=this.cache[this.key(a)];return void 0===b?c:c[b]},access:function(a,b,c){var d;return void 0===b||b&&"string"==typeof b&&void 0===c?(d=this.get(a,b),void 0!==d?d:this.get(a,n.camelCase(b))):(this.set(a,b,c),void 0!==c?c:b)},remove:function(a,b){var c,d,e,f=this.key(a),g=this.cache[f];if(void 0===b)this.cache[f]={};else{n.isArray(b)?d=b.concat(b.map(n.camelCase)):(e=n.camelCase(b),b in g?d=[b,e]:(d=e,d=d in g?[d]:d.match(E)||[])),c=d.length;while(c--)delete g[d[c]]}},hasData:function(a){return!n.isEmptyObject(this.cache[a[this.expando]]||{})},discard:function(a){a[this.expando]&&delete this.cache[a[this.expando]]}};var L=new K,M=new K,N=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,O=/([A-Z])/g;function P(a,b,c){var d;if(void 0===c&&1===a.nodeType)if(d="data-"+b.replace(O,"-$1").toLowerCase(),c=a.getAttribute(d),"string"==typeof c){try{c="true"===c?!0:"false"===c?!1:"null"===c?null:+c+""===c?+c:N.test(c)?n.parseJSON(c):c}catch(e){}M.set(a,b,c)}else c=void 0;return c}n.extend({hasData:function(a){return M.hasData(a)||L.hasData(a)},data:function(a,b,c){
-return M.access(a,b,c)},removeData:function(a,b){M.remove(a,b)},_data:function(a,b,c){return L.access(a,b,c)},_removeData:function(a,b){L.remove(a,b)}}),n.fn.extend({data:function(a,b){var c,d,e,f=this[0],g=f&&f.attributes;if(void 0===a){if(this.length&&(e=M.get(f),1===f.nodeType&&!L.get(f,"hasDataAttrs"))){c=g.length;while(c--)g[c]&&(d=g[c].name,0===d.indexOf("data-")&&(d=n.camelCase(d.slice(5)),P(f,d,e[d])));L.set(f,"hasDataAttrs",!0)}return e}return"object"==typeof a?this.each(function(){M.set(this,a)}):J(this,function(b){var c,d=n.camelCase(a);if(f&&void 0===b){if(c=M.get(f,a),void 0!==c)return c;if(c=M.get(f,d),void 0!==c)return c;if(c=P(f,d,void 0),void 0!==c)return c}else this.each(function(){var c=M.get(this,d);M.set(this,d,b),-1!==a.indexOf("-")&&void 0!==c&&M.set(this,a,b)})},null,b,arguments.length>1,null,!0)},removeData:function(a){return this.each(function(){M.remove(this,a)})}}),n.extend({queue:function(a,b,c){var d;return a?(b=(b||"fx")+"queue",d=L.get(a,b),c&&(!d||n.isArray(c)?d=L.access(a,b,n.makeArray(c)):d.push(c)),d||[]):void 0},dequeue:function(a,b){b=b||"fx";var c=n.queue(a,b),d=c.length,e=c.shift(),f=n._queueHooks(a,b),g=function(){n.dequeue(a,b)};"inprogress"===e&&(e=c.shift(),d--),e&&("fx"===b&&c.unshift("inprogress"),delete f.stop,e.call(a,g,f)),!d&&f&&f.empty.fire()},_queueHooks:function(a,b){var c=b+"queueHooks";return L.get(a,c)||L.access(a,c,{empty:n.Callbacks("once memory").add(function(){L.remove(a,[b+"queue",c])})})}}),n.fn.extend({queue:function(a,b){var c=2;return"string"!=typeof a&&(b=a,a="fx",c--),arguments.length<c?n.queue(this[0],a):void 0===b?this:this.each(function(){var c=n.queue(this,a,b);n._queueHooks(this,a),"fx"===a&&"inprogress"!==c[0]&&n.dequeue(this,a)})},dequeue:function(a){return this.each(function(){n.dequeue(this,a)})},clearQueue:function(a){return this.queue(a||"fx",[])},promise:function(a,b){var c,d=1,e=n.Deferred(),f=this,g=this.length,h=function(){--d||e.resolveWith(f,[f])};"string"!=typeof a&&(b=a,a=void 0),a=a||"fx";while(g--)c=L.get(f[g],a+"queueHooks"),c&&c.empty&&(d++,c.empty.add(h));return h(),e.promise(b)}});var Q=/[+-]?(?:\d*\.|)\d+(?:[eE][+-]?\d+|)/.source,R=["Top","Right","Bottom","Left"],S=function(a,b){return a=b||a,"none"===n.css(a,"display")||!n.contains(a.ownerDocument,a)},T=/^(?:checkbox|radio)$/i;!function(){var a=l.createDocumentFragment(),b=a.appendChild(l.createElement("div")),c=l.createElement("input");c.setAttribute("type","radio"),c.setAttribute("checked","checked"),c.setAttribute("name","t"),b.appendChild(c),k.checkClone=b.cloneNode(!0).cloneNode(!0).lastChild.checked,b.innerHTML="<textarea>x</textarea>",k.noCloneChecked=!!b.cloneNode(!0).lastChild.defaultValue}();var U="undefined";k.focusinBubbles="onfocusin"in a;var V=/^key/,W=/^(?:mouse|pointer|contextmenu)|click/,X=/^(?:focusinfocus|focusoutblur)$/,Y=/^([^.]*)(?:\.(.+)|)$/;function Z(){return!0}function $(){return!1}function _(){try{return l.activeElement}catch(a){}}n.event={global:{},add:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,o,p,q,r=L.get(a);if(r){c.handler&&(f=c,c=f.handler,e=f.selector),c.guid||(c.guid=n.guid++),(i=r.events)||(i=r.events={}),(g=r.handle)||(g=r.handle=function(b){return typeof n!==U&&n.event.triggered!==b.type?n.event.dispatch.apply(a,arguments):void 0}),b=(b||"").match(E)||[""],j=b.length;while(j--)h=Y.exec(b[j])||[],o=q=h[1],p=(h[2]||"").split(".").sort(),o&&(l=n.event.special[o]||{},o=(e?l.delegateType:l.bindType)||o,l=n.event.special[o]||{},k=n.extend({type:o,origType:q,data:d,handler:c,guid:c.guid,selector:e,needsContext:e&&n.expr.match.needsContext.test(e),namespace:p.join(".")},f),(m=i[o])||(m=i[o]=[],m.delegateCount=0,l.setup&&l.setup.call(a,d,p,g)!==!1||a.addEventListener&&a.addEventListener(o,g,!1)),l.add&&(l.add.call(a,k),k.handler.guid||(k.handler.guid=c.guid)),e?m.splice(m.delegateCount++,0,k):m.push(k),n.event.global[o]=!0)}},remove:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,o,p,q,r=L.hasData(a)&&L.get(a);if(r&&(i=r.events)){b=(b||"").match(E)||[""],j=b.length;while(j--)if(h=Y.exec(b[j])||[],o=q=h[1],p=(h[2]||"").split(".").sort(),o){l=n.event.special[o]||{},o=(d?l.delegateType:l.bindType)||o,m=i[o]||[],h=h[2]&&new RegExp("(^|\\.)"+p.join("\\.(?:.*\\.|)")+"(\\.|$)"),g=f=m.length;while(f--)k=m[f],!e&&q!==k.origType||c&&c.guid!==k.guid||h&&!h.test(k.namespace)||d&&d!==k.selector&&("**"!==d||!k.selector)||(m.splice(f,1),k.selector&&m.delegateCount--,l.remove&&l.remove.call(a,k));g&&!m.length&&(l.teardown&&l.teardown.call(a,p,r.handle)!==!1||n.removeEvent(a,o,r.handle),delete i[o])}else for(o in i)n.event.remove(a,o+b[j],c,d,!0);n.isEmptyObject(i)&&(delete r.handle,L.remove(a,"events"))}},trigger:function(b,c,d,e){var f,g,h,i,k,m,o,p=[d||l],q=j.call(b,"type")?b.type:b,r=j.call(b,"namespace")?b.namespace.split("."):[];if(g=h=d=d||l,3!==d.nodeType&&8!==d.nodeType&&!X.test(q+n.event.triggered)&&(q.indexOf(".")>=0&&(r=q.split("."),q=r.shift(),r.sort()),k=q.indexOf(":")<0&&"on"+q,b=b[n.expando]?b:new n.Event(q,"object"==typeof b&&b),b.isTrigger=e?2:3,b.namespace=r.join("."),b.namespace_re=b.namespace?new RegExp("(^|\\.)"+r.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,b.result=void 0,b.target||(b.target=d),c=null==c?[b]:n.makeArray(c,[b]),o=n.event.special[q]||{},e||!o.trigger||o.trigger.apply(d,c)!==!1)){if(!e&&!o.noBubble&&!n.isWindow(d)){for(i=o.delegateType||q,X.test(i+q)||(g=g.parentNode);g;g=g.parentNode)p.push(g),h=g;h===(d.ownerDocument||l)&&p.push(h.defaultView||h.parentWindow||a)}f=0;while((g=p[f++])&&!b.isPropagationStopped())b.type=f>1?i:o.bindType||q,m=(L.get(g,"events")||{})[b.type]&&L.get(g,"handle"),m&&m.apply(g,c),m=k&&g[k],m&&m.apply&&n.acceptData(g)&&(b.result=m.apply(g,c),b.result===!1&&b.preventDefault());return b.type=q,e||b.isDefaultPrevented()||o._default&&o._default.apply(p.pop(),c)!==!1||!n.acceptData(d)||k&&n.isFunction(d[q])&&!n.isWindow(d)&&(h=d[k],h&&(d[k]=null),n.event.triggered=q,d[q](),n.event.triggered=void 0,h&&(d[k]=h)),b.result}},dispatch:function(a){a=n.event.fix(a);var b,c,e,f,g,h=[],i=d.call(arguments),j=(L.get(this,"events")||{})[a.type]||[],k=n.event.special[a.type]||{};if(i[0]=a,a.delegateTarget=this,!k.preDispatch||k.preDispatch.call(this,a)!==!1){h=n.event.handlers.call(this,a,j),b=0;while((f=h[b++])&&!a.isPropagationStopped()){a.currentTarget=f.elem,c=0;while((g=f.handlers[c++])&&!a.isImmediatePropagationStopped())(!a.namespace_re||a.namespace_re.test(g.namespace))&&(a.handleObj=g,a.data=g.data,e=((n.event.special[g.origType]||{}).handle||g.handler).apply(f.elem,i),void 0!==e&&(a.result=e)===!1&&(a.preventDefault(),a.stopPropagation()))}return k.postDispatch&&k.postDispatch.call(this,a),a.result}},handlers:function(a,b){var c,d,e,f,g=[],h=b.delegateCount,i=a.target;if(h&&i.nodeType&&(!a.button||"click"!==a.type))for(;i!==this;i=i.parentNode||this)if(i.disabled!==!0||"click"!==a.type){for(d=[],c=0;h>c;c++)f=b[c],e=f.selector+" ",void 0===d[e]&&(d[e]=f.needsContext?n(e,this).index(i)>=0:n.find(e,this,null,[i]).length),d[e]&&d.push(f);d.length&&g.push({elem:i,handlers:d})}return h<b.length&&g.push({elem:this,handlers:b.slice(h)}),g},props:"altKey bubbles cancelable ctrlKey currentTarget eventPhase metaKey relatedTarget shiftKey target timeStamp view which".split(" "),fixHooks:{},keyHooks:{props:"char charCode key keyCode".split(" "),filter:function(a,b){return null==a.which&&(a.which=null!=b.charCode?b.charCode:b.keyCode),a}},mouseHooks:{props:"button buttons clientX clientY offsetX offsetY pageX pageY screenX screenY toElement".split(" "),filter:function(a,b){var c,d,e,f=b.button;return null==a.pageX&&null!=b.clientX&&(c=a.target.ownerDocument||l,d=c.documentElement,e=c.body,a.pageX=b.clientX+(d&&d.scrollLeft||e&&e.scrollLeft||0)-(d&&d.clientLeft||e&&e.clientLeft||0),a.pageY=b.clientY+(d&&d.scrollTop||e&&e.scrollTop||0)-(d&&d.clientTop||e&&e.clientTop||0)),a.which||void 0===f||(a.which=1&f?1:2&f?3:4&f?2:0),a}},fix:function(a){if(a[n.expando])return a;var b,c,d,e=a.type,f=a,g=this.fixHooks[e];g||(this.fixHooks[e]=g=W.test(e)?this.mouseHooks:V.test(e)?this.keyHooks:{}),d=g.props?this.props.concat(g.props):this.props,a=new n.Event(f),b=d.length;while(b--)c=d[b],a[c]=f[c];return a.target||(a.target=l),3===a.target.nodeType&&(a.target=a.target.parentNode),g.filter?g.filter(a,f):a},special:{load:{noBubble:!0},focus:{trigger:function(){return this!==_()&&this.focus?(this.focus(),!1):void 0},delegateType:"focusin"},blur:{trigger:function(){return this===_()&&this.blur?(this.blur(),!1):void 0},delegateType:"focusout"},click:{trigger:function(){return"checkbox"===this.type&&this.click&&n.nodeName(this,"input")?(this.click(),!1):void 0},_default:function(a){return n.nodeName(a.target,"a")}},beforeunload:{postDispatch:function(a){void 0!==a.result&&a.originalEvent&&(a.originalEvent.returnValue=a.result)}}},simulate:function(a,b,c,d){var e=n.extend(new n.Event,c,{type:a,isSimulated:!0,originalEvent:{}});d?n.event.trigger(e,null,b):n.event.dispatch.call(b,e),e.isDefaultPrevented()&&c.preventDefault()}},n.removeEvent=function(a,b,c){a.removeEventListener&&a.removeEventListener(b,c,!1)},n.Event=function(a,b){return this instanceof n.Event?(a&&a.type?(this.originalEvent=a,this.type=a.type,this.isDefaultPrevented=a.defaultPrevented||void 0===a.defaultPrevented&&a.returnValue===!1?Z:$):this.type=a,b&&n.extend(this,b),this.timeStamp=a&&a.timeStamp||n.now(),void(this[n.expando]=!0)):new n.Event(a,b)},n.Event.prototype={isDefaultPrevented:$,isPropagationStopped:$,isImmediatePropagationStopped:$,preventDefault:function(){var a=this.originalEvent;this.isDefaultPrevented=Z,a&&a.preventDefault&&a.preventDefault()},stopPropagation:function(){var a=this.originalEvent;this.isPropagationStopped=Z,a&&a.stopPropagation&&a.stopPropagation()},stopImmediatePropagation:function(){var a=this.originalEvent;this.isImmediatePropagationStopped=Z,a&&a.stopImmediatePropagation&&a.stopImmediatePropagation(),this.stopPropagation()}},n.each({mouseenter:"mouseover",mouseleave:"mouseout",pointerenter:"pointerover",pointerleave:"pointerout"},function(a,b){n.event.special[a]={delegateType:b,bindType:b,handle:function(a){var c,d=this,e=a.relatedTarget,f=a.handleObj;return(!e||e!==d&&!n.contains(d,e))&&(a.type=f.origType,c=f.handler.apply(this,arguments),a.type=b),c}}}),k.focusinBubbles||n.each({focus:"focusin",blur:"focusout"},function(a,b){var c=function(a){n.event.simulate(b,a.target,n.event.fix(a),!0)};n.event.special[b]={setup:function(){var d=this.ownerDocument||this,e=L.access(d,b);e||d.addEventListener(a,c,!0),L.access(d,b,(e||0)+1)},teardown:function(){var d=this.ownerDocument||this,e=L.access(d,b)-1;e?L.access(d,b,e):(d.removeEventListener(a,c,!0),L.remove(d,b))}}}),n.fn.extend({on:function(a,b,c,d,e){var f,g;if("object"==typeof a){"string"!=typeof b&&(c=c||b,b=void 0);for(g in a)this.on(g,b,c,a[g],e);return this}if(null==c&&null==d?(d=b,c=b=void 0):null==d&&("string"==typeof b?(d=c,c=void 0):(d=c,c=b,b=void 0)),d===!1)d=$;else if(!d)return this;return 1===e&&(f=d,d=function(a){return n().off(a),f.apply(this,arguments)},d.guid=f.guid||(f.guid=n.guid++)),this.each(function(){n.event.add(this,a,d,c,b)})},one:function(a,b,c,d){return this.on(a,b,c,d,1)},off:function(a,b,c){var d,e;if(a&&a.preventDefault&&a.handleObj)return d=a.handleObj,n(a.delegateTarget).off(d.namespace?d.origType+"."+d.namespace:d.origType,d.selector,d.handler),this;if("object"==typeof a){for(e in a)this.off(e,b,a[e]);return this}return(b===!1||"function"==typeof b)&&(c=b,b=void 0),c===!1&&(c=$),this.each(function(){n.event.remove(this,a,c,b)})},trigger:function(a,b){return this.each(function(){n.event.trigger(a,b,this)})},triggerHandler:function(a,b){var c=this[0];return c?n.event.trigger(a,b,c,!0):void 0}});var aa=/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([\w:]+)[^>]*)\/>/gi,ba=/<([\w:]+)/,ca=/<|&#?\w+;/,da=/<(?:script|style|link)/i,ea=/checked\s*(?:[^=]|=\s*.checked.)/i,fa=/^$|\/(?:java|ecma)script/i,ga=/^true\/(.*)/,ha=/^\s*<!(?:\[CDATA\[|--)|(?:\]\]|--)>\s*$/g,ia={option:[1,"<select multiple='multiple'>","</select>"],thead:[1,"<table>","</table>"],col:[2,"<table><colgroup>","</colgroup></table>"],tr:[2,"<table><tbody>","</tbody></table>"],td:[3,"<table><tbody><tr>","</tr></tbody></table>"],_default:[0,"",""]};ia.optgroup=ia.option,ia.tbody=ia.tfoot=ia.colgroup=ia.caption=ia.thead,ia.th=ia.td;function ja(a,b){return n.nodeName(a,"table")&&n.nodeName(11!==b.nodeType?b:b.firstChild,"tr")?a.getElementsByTagName("tbody")[0]||a.appendChild(a.ownerDocument.createElement("tbody")):a}function ka(a){return a.type=(null!==a.getAttribute("type"))+"/"+a.type,a}function la(a){var b=ga.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function ma(a,b){for(var c=0,d=a.length;d>c;c++)L.set(a[c],"globalEval",!b||L.get(b[c],"globalEval"))}function na(a,b){var c,d,e,f,g,h,i,j;if(1===b.nodeType){if(L.hasData(a)&&(f=L.access(a),g=L.set(b,f),j=f.events)){delete g.handle,g.events={};for(e in j)for(c=0,d=j[e].length;d>c;c++)n.event.add(b,e,j[e][c])}M.hasData(a)&&(h=M.access(a),i=n.extend({},h),M.set(b,i))}}function oa(a,b){var c=a.getElementsByTagName?a.getElementsByTagName(b||"*"):a.querySelectorAll?a.querySelectorAll(b||"*"):[];return void 0===b||b&&n.nodeName(a,b)?n.merge([a],c):c}function pa(a,b){var c=b.nodeName.toLowerCase();"input"===c&&T.test(a.type)?b.checked=a.checked:("input"===c||"textarea"===c)&&(b.defaultValue=a.defaultValue)}n.extend({clone:function(a,b,c){var d,e,f,g,h=a.cloneNode(!0),i=n.contains(a.ownerDocument,a);if(!(k.noCloneChecked||1!==a.nodeType&&11!==a.nodeType||n.isXMLDoc(a)))for(g=oa(h),f=oa(a),d=0,e=f.length;e>d;d++)pa(f[d],g[d]);if(b)if(c)for(f=f||oa(a),g=g||oa(h),d=0,e=f.length;e>d;d++)na(f[d],g[d]);else na(a,h);return g=oa(h,"script"),g.length>0&&ma(g,!i&&oa(a,"script")),h},buildFragment:function(a,b,c,d){for(var e,f,g,h,i,j,k=b.createDocumentFragment(),l=[],m=0,o=a.length;o>m;m++)if(e=a[m],e||0===e)if("object"===n.type(e))n.merge(l,e.nodeType?[e]:e);else if(ca.test(e)){f=f||k.appendChild(b.createElement("div")),g=(ba.exec(e)||["",""])[1].toLowerCase(),h=ia[g]||ia._default,f.innerHTML=h[1]+e.replace(aa,"<$1></$2>")+h[2],j=h[0];while(j--)f=f.lastChild;n.merge(l,f.childNodes),f=k.firstChild,f.textContent=""}else l.push(b.createTextNode(e));k.textContent="",m=0;while(e=l[m++])if((!d||-1===n.inArray(e,d))&&(i=n.contains(e.ownerDocument,e),f=oa(k.appendChild(e),"script"),i&&ma(f),c)){j=0;while(e=f[j++])fa.test(e.type||"")&&c.push(e)}return k},cleanData:function(a){for(var b,c,d,e,f=n.event.special,g=0;void 0!==(c=a[g]);g++){if(n.acceptData(c)&&(e=c[L.expando],e&&(b=L.cache[e]))){if(b.events)for(d in b.events)f[d]?n.event.remove(c,d):n.removeEvent(c,d,b.handle);L.cache[e]&&delete L.cache[e]}delete M.cache[c[M.expando]]}}}),n.fn.extend({text:function(a){return J(this,function(a){return void 0===a?n.text(this):this.empty().each(function(){(1===this.nodeType||11===this.nodeType||9===this.nodeType)&&(this.textContent=a)})},null,a,arguments.length)},append:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=ja(this,a);b.appendChild(a)}})},prepend:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=ja(this,a);b.insertBefore(a,b.firstChild)}})},before:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this)})},after:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this.nextSibling)})},remove:function(a,b){for(var c,d=a?n.filter(a,this):this,e=0;null!=(c=d[e]);e++)b||1!==c.nodeType||n.cleanData(oa(c)),c.parentNode&&(b&&n.contains(c.ownerDocument,c)&&ma(oa(c,"script")),c.parentNode.removeChild(c));return this},empty:function(){for(var a,b=0;null!=(a=this[b]);b++)1===a.nodeType&&(n.cleanData(oa(a,!1)),a.textContent="");return this},clone:function(a,b){return a=null==a?!1:a,b=null==b?a:b,this.map(function(){return n.clone(this,a,b)})},html:function(a){return J(this,function(a){var b=this[0]||{},c=0,d=this.length;if(void 0===a&&1===b.nodeType)return b.innerHTML;if("string"==typeof a&&!da.test(a)&&!ia[(ba.exec(a)||["",""])[1].toLowerCase()]){a=a.replace(aa,"<$1></$2>");try{for(;d>c;c++)b=this[c]||{},1===b.nodeType&&(n.cleanData(oa(b,!1)),b.innerHTML=a);b=0}catch(e){}}b&&this.empty().append(a)},null,a,arguments.length)},replaceWith:function(){var a=arguments[0];return this.domManip(arguments,function(b){a=this.parentNode,n.cleanData(oa(this)),a&&a.replaceChild(b,this)}),a&&(a.length||a.nodeType)?this:this.remove()},detach:function(a){return this.remove(a,!0)},domManip:function(a,b){a=e.apply([],a);var c,d,f,g,h,i,j=0,l=this.length,m=this,o=l-1,p=a[0],q=n.isFunction(p);if(q||l>1&&"string"==typeof p&&!k.checkClone&&ea.test(p))return this.each(function(c){var d=m.eq(c);q&&(a[0]=p.call(this,c,d.html())),d.domManip(a,b)});if(l&&(c=n.buildFragment(a,this[0].ownerDocument,!1,this),d=c.firstChild,1===c.childNodes.length&&(c=d),d)){for(f=n.map(oa(c,"script"),ka),g=f.length;l>j;j++)h=c,j!==o&&(h=n.clone(h,!0,!0),g&&n.merge(f,oa(h,"script"))),b.call(this[j],h,j);if(g)for(i=f[f.length-1].ownerDocument,n.map(f,la),j=0;g>j;j++)h=f[j],fa.test(h.type||"")&&!L.access(h,"globalEval")&&n.contains(i,h)&&(h.src?n._evalUrl&&n._evalUrl(h.src):n.globalEval(h.textContent.replace(ha,"")))}return this}}),n.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){n.fn[a]=function(a){for(var c,d=[],e=n(a),g=e.length-1,h=0;g>=h;h++)c=h===g?this:this.clone(!0),n(e[h])[b](c),f.apply(d,c.get());return this.pushStack(d)}});var qa,ra={};function sa(b,c){var d,e=n(c.createElement(b)).appendTo(c.body),f=a.getDefaultComputedStyle&&(d=a.getDefaultComputedStyle(e[0]))?d.display:n.css(e[0],"display");return e.detach(),f}function ta(a){var b=l,c=ra[a];return c||(c=sa(a,b),"none"!==c&&c||(qa=(qa||n("<iframe frameborder='0' width='0' height='0'/>")).appendTo(b.documentElement),b=qa[0].contentDocument,b.write(),b.close(),c=sa(a,b),qa.detach()),ra[a]=c),c}var ua=/^margin/,va=new RegExp("^("+Q+")(?!px)[a-z%]+$","i"),wa=function(b){return b.ownerDocument.defaultView.opener?b.ownerDocument.defaultView.getComputedStyle(b,null):a.getComputedStyle(b,null)};function xa(a,b,c){var d,e,f,g,h=a.style;return c=c||wa(a),c&&(g=c.getPropertyValue(b)||c[b]),c&&(""!==g||n.contains(a.ownerDocument,a)||(g=n.style(a,b)),va.test(g)&&ua.test(b)&&(d=h.width,e=h.minWidth,f=h.maxWidth,h.minWidth=h.maxWidth=h.width=g,g=c.width,h.width=d,h.minWidth=e,h.maxWidth=f)),void 0!==g?g+"":g}function ya(a,b){return{get:function(){return a()?void delete this.get:(this.get=b).apply(this,arguments)}}}!function(){var b,c,d=l.documentElement,e=l.createElement("div"),f=l.createElement("div");if(f.style){f.style.backgroundClip="content-box",f.cloneNode(!0).style.backgroundClip="",k.clearCloneStyle="content-box"===f.style.backgroundClip,e.style.cssText="border:0;width:0;height:0;top:0;left:-9999px;margin-top:1px;position:absolute",e.appendChild(f);function g(){f.style.cssText="-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;display:block;margin-top:1%;top:1%;border:1px;padding:1px;width:4px;position:absolute",f.innerHTML="",d.appendChild(e);var g=a.getComputedStyle(f,null);b="1%"!==g.top,c="4px"===g.width,d.removeChild(e)}a.getComputedStyle&&n.extend(k,{pixelPosition:function(){return g(),b},boxSizingReliable:function(){return null==c&&g(),c},reliableMarginRight:function(){var b,c=f.appendChild(l.createElement("div"));return c.style.cssText=f.style.cssText="-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box;display:block;margin:0;border:0;padding:0",c.style.marginRight=c.style.width="0",f.style.width="1px",d.appendChild(e),b=!parseFloat(a.getComputedStyle(c,null).marginRight),d.removeChild(e),f.removeChild(c),b}})}}(),n.swap=function(a,b,c,d){var e,f,g={};for(f in b)g[f]=a.style[f],a.style[f]=b[f];e=c.apply(a,d||[]);for(f in b)a.style[f]=g[f];return e};var za=/^(none|table(?!-c[ea]).+)/,Aa=new RegExp("^("+Q+")(.*)$","i"),Ba=new RegExp("^([+-])=("+Q+")","i"),Ca={position:"absolute",visibility:"hidden",display:"block"},Da={letterSpacing:"0",fontWeight:"400"},Ea=["Webkit","O","Moz","ms"];function Fa(a,b){if(b in a)return b;var c=b[0].toUpperCase()+b.slice(1),d=b,e=Ea.length;while(e--)if(b=Ea[e]+c,b in a)return b;return d}function Ga(a,b,c){var d=Aa.exec(b);return d?Math.max(0,d[1]-(c||0))+(d[2]||"px"):b}function Ha(a,b,c,d,e){for(var f=c===(d?"border":"content")?4:"width"===b?1:0,g=0;4>f;f+=2)"margin"===c&&(g+=n.css(a,c+R[f],!0,e)),d?("content"===c&&(g-=n.css(a,"padding"+R[f],!0,e)),"margin"!==c&&(g-=n.css(a,"border"+R[f]+"Width",!0,e))):(g+=n.css(a,"padding"+R[f],!0,e),"padding"!==c&&(g+=n.css(a,"border"+R[f]+"Width",!0,e)));return g}function Ia(a,b,c){var d=!0,e="width"===b?a.offsetWidth:a.offsetHeight,f=wa(a),g="border-box"===n.css(a,"boxSizing",!1,f);if(0>=e||null==e){if(e=xa(a,b,f),(0>e||null==e)&&(e=a.style[b]),va.test(e))return e;d=g&&(k.boxSizingReliable()||e===a.style[b]),e=parseFloat(e)||0}return e+Ha(a,b,c||(g?"border":"content"),d,f)+"px"}function Ja(a,b){for(var c,d,e,f=[],g=0,h=a.length;h>g;g++)d=a[g],d.style&&(f[g]=L.get(d,"olddisplay"),c=d.style.display,b?(f[g]||"none"!==c||(d.style.display=""),""===d.style.display&&S(d)&&(f[g]=L.access(d,"olddisplay",ta(d.nodeName)))):(e=S(d),"none"===c&&e||L.set(d,"olddisplay",e?c:n.css(d,"display"))));for(g=0;h>g;g++)d=a[g],d.style&&(b&&"none"!==d.style.display&&""!==d.style.display||(d.style.display=b?f[g]||"":"none"));return a}n.extend({cssHooks:{opacity:{get:function(a,b){if(b){var c=xa(a,"opacity");return""===c?"1":c}}}},cssNumber:{columnCount:!0,fillOpacity:!0,flexGrow:!0,flexShrink:!0,fontWeight:!0,lineHeight:!0,opacity:!0,order:!0,orphans:!0,widows:!0,zIndex:!0,zoom:!0},cssProps:{"float":"cssFloat"},style:function(a,b,c,d){if(a&&3!==a.nodeType&&8!==a.nodeType&&a.style){var e,f,g,h=n.camelCase(b),i=a.style;return b=n.cssProps[h]||(n.cssProps[h]=Fa(i,h)),g=n.cssHooks[b]||n.cssHooks[h],void 0===c?g&&"get"in g&&void 0!==(e=g.get(a,!1,d))?e:i[b]:(f=typeof c,"string"===f&&(e=Ba.exec(c))&&(c=(e[1]+1)*e[2]+parseFloat(n.css(a,b)),f="number"),null!=c&&c===c&&("number"!==f||n.cssNumber[h]||(c+="px"),k.clearCloneStyle||""!==c||0!==b.indexOf("background")||(i[b]="inherit"),g&&"set"in g&&void 0===(c=g.set(a,c,d))||(i[b]=c)),void 0)}},css:function(a,b,c,d){var e,f,g,h=n.camelCase(b);return b=n.cssProps[h]||(n.cssProps[h]=Fa(a.style,h)),g=n.cssHooks[b]||n.cssHooks[h],g&&"get"in g&&(e=g.get(a,!0,c)),void 0===e&&(e=xa(a,b,d)),"normal"===e&&b in Da&&(e=Da[b]),""===c||c?(f=parseFloat(e),c===!0||n.isNumeric(f)?f||0:e):e}}),n.each(["height","width"],function(a,b){n.cssHooks[b]={get:function(a,c,d){return c?za.test(n.css(a,"display"))&&0===a.offsetWidth?n.swap(a,Ca,function(){return Ia(a,b,d)}):Ia(a,b,d):void 0},set:function(a,c,d){var e=d&&wa(a);return Ga(a,c,d?Ha(a,b,d,"border-box"===n.css(a,"boxSizing",!1,e),e):0)}}}),n.cssHooks.marginRight=ya(k.reliableMarginRight,function(a,b){return b?n.swap(a,{display:"inline-block"},xa,[a,"marginRight"]):void 0}),n.each({margin:"",padding:"",border:"Width"},function(a,b){n.cssHooks[a+b]={expand:function(c){for(var d=0,e={},f="string"==typeof c?c.split(" "):[c];4>d;d++)e[a+R[d]+b]=f[d]||f[d-2]||f[0];return e}},ua.test(a)||(n.cssHooks[a+b].set=Ga)}),n.fn.extend({css:function(a,b){return J(this,function(a,b,c){var d,e,f={},g=0;if(n.isArray(b)){for(d=wa(a),e=b.length;e>g;g++)f[b[g]]=n.css(a,b[g],!1,d);return f}return void 0!==c?n.style(a,b,c):n.css(a,b)},a,b,arguments.length>1)},show:function(){return Ja(this,!0)},hide:function(){return Ja(this)},toggle:function(a){return"boolean"==typeof a?a?this.show():this.hide():this.each(function(){S(this)?n(this).show():n(this).hide()})}});function Ka(a,b,c,d,e){return new Ka.prototype.init(a,b,c,d,e)}n.Tween=Ka,Ka.prototype={constructor:Ka,init:function(a,b,c,d,e,f){this.elem=a,this.prop=c,this.easing=e||"swing",this.options=b,this.start=this.now=this.cur(),this.end=d,this.unit=f||(n.cssNumber[c]?"":"px")},cur:function(){var a=Ka.propHooks[this.prop];return a&&a.get?a.get(this):Ka.propHooks._default.get(this)},run:function(a){var b,c=Ka.propHooks[this.prop];return this.options.duration?this.pos=b=n.easing[this.easing](a,this.options.duration*a,0,1,this.options.duration):this.pos=b=a,this.now=(this.end-this.start)*b+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),c&&c.set?c.set(this):Ka.propHooks._default.set(this),this}},Ka.prototype.init.prototype=Ka.prototype,Ka.propHooks={_default:{get:function(a){var b;return null==a.elem[a.prop]||a.elem.style&&null!=a.elem.style[a.prop]?(b=n.css(a.elem,a.prop,""),b&&"auto"!==b?b:0):a.elem[a.prop]},set:function(a){n.fx.step[a.prop]?n.fx.step[a.prop](a):a.elem.style&&(null!=a.elem.style[n.cssProps[a.prop]]||n.cssHooks[a.prop])?n.style(a.elem,a.prop,a.now+a.unit):a.elem[a.prop]=a.now}}},Ka.propHooks.scrollTop=Ka.propHooks.scrollLeft={set:function(a){a.elem.nodeType&&a.elem.parentNode&&(a.elem[a.prop]=a.now)}},n.easing={linear:function(a){return a},swing:function(a){return.5-Math.cos(a*Math.PI)/2}},n.fx=Ka.prototype.init,n.fx.step={};var La,Ma,Na=/^(?:toggle|show|hide)$/,Oa=new RegExp("^(?:([+-])=|)("+Q+")([a-z%]*)$","i"),Pa=/queueHooks$/,Qa=[Va],Ra={"*":[function(a,b){var c=this.createTween(a,b),d=c.cur(),e=Oa.exec(b),f=e&&e[3]||(n.cssNumber[a]?"":"px"),g=(n.cssNumber[a]||"px"!==f&&+d)&&Oa.exec(n.css(c.elem,a)),h=1,i=20;if(g&&g[3]!==f){f=f||g[3],e=e||[],g=+d||1;do h=h||".5",g/=h,n.style(c.elem,a,g+f);while(h!==(h=c.cur()/d)&&1!==h&&--i)}return e&&(g=c.start=+g||+d||0,c.unit=f,c.end=e[1]?g+(e[1]+1)*e[2]:+e[2]),c}]};function Sa(){return setTimeout(function(){La=void 0}),La=n.now()}function Ta(a,b){var c,d=0,e={height:a};for(b=b?1:0;4>d;d+=2-b)c=R[d],e["margin"+c]=e["padding"+c]=a;return b&&(e.opacity=e.width=a),e}function Ua(a,b,c){for(var d,e=(Ra[b]||[]).concat(Ra["*"]),f=0,g=e.length;g>f;f++)if(d=e[f].call(c,b,a))return d}function Va(a,b,c){var d,e,f,g,h,i,j,k,l=this,m={},o=a.style,p=a.nodeType&&S(a),q=L.get(a,"fxshow");c.queue||(h=n._queueHooks(a,"fx"),null==h.unqueued&&(h.unqueued=0,i=h.empty.fire,h.empty.fire=function(){h.unqueued||i()}),h.unqueued++,l.always(function(){l.always(function(){h.unqueued--,n.queue(a,"fx").length||h.empty.fire()})})),1===a.nodeType&&("height"in b||"width"in b)&&(c.overflow=[o.overflow,o.overflowX,o.overflowY],j=n.css(a,"display"),k="none"===j?L.get(a,"olddisplay")||ta(a.nodeName):j,"inline"===k&&"none"===n.css(a,"float")&&(o.display="inline-block")),c.overflow&&(o.overflow="hidden",l.always(function(){o.overflow=c.overflow[0],o.overflowX=c.overflow[1],o.overflowY=c.overflow[2]}));for(d in b)if(e=b[d],Na.exec(e)){if(delete b[d],f=f||"toggle"===e,e===(p?"hide":"show")){if("show"!==e||!q||void 0===q[d])continue;p=!0}m[d]=q&&q[d]||n.style(a,d)}else j=void 0;if(n.isEmptyObject(m))"inline"===("none"===j?ta(a.nodeName):j)&&(o.display=j);else{q?"hidden"in q&&(p=q.hidden):q=L.access(a,"fxshow",{}),f&&(q.hidden=!p),p?n(a).show():l.done(function(){n(a).hide()}),l.done(function(){var b;L.remove(a,"fxshow");for(b in m)n.style(a,b,m[b])});for(d in m)g=Ua(p?q[d]:0,d,l),d in q||(q[d]=g.start,p&&(g.end=g.start,g.start="width"===d||"height"===d?1:0))}}function Wa(a,b){var c,d,e,f,g;for(c in a)if(d=n.camelCase(c),e=b[d],f=a[c],n.isArray(f)&&(e=f[1],f=a[c]=f[0]),c!==d&&(a[d]=f,delete a[c]),g=n.cssHooks[d],g&&"expand"in g){f=g.expand(f),delete a[d];for(c in f)c in a||(a[c]=f[c],b[c]=e)}else b[d]=e}function Xa(a,b,c){var d,e,f=0,g=Qa.length,h=n.Deferred().always(function(){delete i.elem}),i=function(){if(e)return!1;for(var b=La||Sa(),c=Math.max(0,j.startTime+j.duration-b),d=c/j.duration||0,f=1-d,g=0,i=j.tweens.length;i>g;g++)j.tweens[g].run(f);return h.notifyWith(a,[j,f,c]),1>f&&i?c:(h.resolveWith(a,[j]),!1)},j=h.promise({elem:a,props:n.extend({},b),opts:n.extend(!0,{specialEasing:{}},c),originalProperties:b,originalOptions:c,startTime:La||Sa(),duration:c.duration,tweens:[],createTween:function(b,c){var d=n.Tween(a,j.opts,b,c,j.opts.specialEasing[b]||j.opts.easing);return j.tweens.push(d),d},stop:function(b){var c=0,d=b?j.tweens.length:0;if(e)return this;for(e=!0;d>c;c++)j.tweens[c].run(1);return b?h.resolveWith(a,[j,b]):h.rejectWith(a,[j,b]),this}}),k=j.props;for(Wa(k,j.opts.specialEasing);g>f;f++)if(d=Qa[f].call(j,a,k,j.opts))return d;return n.map(k,Ua,j),n.isFunction(j.opts.start)&&j.opts.start.call(a,j),n.fx.timer(n.extend(i,{elem:a,anim:j,queue:j.opts.queue})),j.progress(j.opts.progress).done(j.opts.done,j.opts.complete).fail(j.opts.fail).always(j.opts.always)}n.Animation=n.extend(Xa,{tweener:function(a,b){n.isFunction(a)?(b=a,a=["*"]):a=a.split(" ");for(var c,d=0,e=a.length;e>d;d++)c=a[d],Ra[c]=Ra[c]||[],Ra[c].unshift(b)},prefilter:function(a,b){b?Qa.unshift(a):Qa.push(a)}}),n.speed=function(a,b,c){var d=a&&"object"==typeof a?n.extend({},a):{complete:c||!c&&b||n.isFunction(a)&&a,duration:a,easing:c&&b||b&&!n.isFunction(b)&&b};return d.duration=n.fx.off?0:"number"==typeof d.duration?d.duration:d.duration in n.fx.speeds?n.fx.speeds[d.duration]:n.fx.speeds._default,(null==d.queue||d.queue===!0)&&(d.queue="fx"),d.old=d.complete,d.complete=function(){n.isFunction(d.old)&&d.old.call(this),d.queue&&n.dequeue(this,d.queue)},d},n.fn.extend({fadeTo:function(a,b,c,d){return this.filter(S).css("opacity",0).show().end().animate({opacity:b},a,c,d)},animate:function(a,b,c,d){var e=n.isEmptyObject(a),f=n.speed(b,c,d),g=function(){var b=Xa(this,n.extend({},a),f);(e||L.get(this,"finish"))&&b.stop(!0)};return g.finish=g,e||f.queue===!1?this.each(g):this.queue(f.queue,g)},stop:function(a,b,c){var d=function(a){var b=a.stop;delete a.stop,b(c)};return"string"!=typeof a&&(c=b,b=a,a=void 0),b&&a!==!1&&this.queue(a||"fx",[]),this.each(function(){var b=!0,e=null!=a&&a+"queueHooks",f=n.timers,g=L.get(this);if(e)g[e]&&g[e].stop&&d(g[e]);else for(e in g)g[e]&&g[e].stop&&Pa.test(e)&&d(g[e]);for(e=f.length;e--;)f[e].elem!==this||null!=a&&f[e].queue!==a||(f[e].anim.stop(c),b=!1,f.splice(e,1));(b||!c)&&n.dequeue(this,a)})},finish:function(a){return a!==!1&&(a=a||"fx"),this.each(function(){var b,c=L.get(this),d=c[a+"queue"],e=c[a+"queueHooks"],f=n.timers,g=d?d.length:0;for(c.finish=!0,n.queue(this,a,[]),e&&e.stop&&e.stop.call(this,!0),b=f.length;b--;)f[b].elem===this&&f[b].queue===a&&(f[b].anim.stop(!0),f.splice(b,1));for(b=0;g>b;b++)d[b]&&d[b].finish&&d[b].finish.call(this);delete c.finish})}}),n.each(["toggle","show","hide"],function(a,b){var c=n.fn[b];n.fn[b]=function(a,d,e){return null==a||"boolean"==typeof a?c.apply(this,arguments):this.animate(Ta(b,!0),a,d,e)}}),n.each({slideDown:Ta("show"),slideUp:Ta("hide"),slideToggle:Ta("toggle"),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"},fadeToggle:{opacity:"toggle"}},function(a,b){n.fn[a]=function(a,c,d){return this.animate(b,a,c,d)}}),n.timers=[],n.fx.tick=function(){var a,b=0,c=n.timers;for(La=n.now();b<c.length;b++)a=c[b],a()||c[b]!==a||c.splice(b--,1);c.length||n.fx.stop(),La=void 0},n.fx.timer=function(a){n.timers.push(a),a()?n.fx.start():n.timers.pop()},n.fx.interval=13,n.fx.start=function(){Ma||(Ma=setInterval(n.fx.tick,n.fx.interval))},n.fx.stop=function(){clearInterval(Ma),Ma=null},n.fx.speeds={slow:600,fast:200,_default:400},n.fn.delay=function(a,b){return a=n.fx?n.fx.speeds[a]||a:a,b=b||"fx",this.queue(b,function(b,c){var d=setTimeout(b,a);c.stop=function(){clearTimeout(d)}})},function(){var a=l.createElement("input"),b=l.createElement("select"),c=b.appendChild(l.createElement("option"));a.type="checkbox",k.checkOn=""!==a.value,k.optSelected=c.selected,b.disabled=!0,k.optDisabled=!c.disabled,a=l.createElement("input"),a.value="t",a.type="radio",k.radioValue="t"===a.value}();var Ya,Za,$a=n.expr.attrHandle;n.fn.extend({attr:function(a,b){return J(this,n.attr,a,b,arguments.length>1)},removeAttr:function(a){return this.each(function(){n.removeAttr(this,a)})}}),n.extend({attr:function(a,b,c){var d,e,f=a.nodeType;if(a&&3!==f&&8!==f&&2!==f)return typeof a.getAttribute===U?n.prop(a,b,c):(1===f&&n.isXMLDoc(a)||(b=b.toLowerCase(),d=n.attrHooks[b]||(n.expr.match.bool.test(b)?Za:Ya)),
-void 0===c?d&&"get"in d&&null!==(e=d.get(a,b))?e:(e=n.find.attr(a,b),null==e?void 0:e):null!==c?d&&"set"in d&&void 0!==(e=d.set(a,c,b))?e:(a.setAttribute(b,c+""),c):void n.removeAttr(a,b))},removeAttr:function(a,b){var c,d,e=0,f=b&&b.match(E);if(f&&1===a.nodeType)while(c=f[e++])d=n.propFix[c]||c,n.expr.match.bool.test(c)&&(a[d]=!1),a.removeAttribute(c)},attrHooks:{type:{set:function(a,b){if(!k.radioValue&&"radio"===b&&n.nodeName(a,"input")){var c=a.value;return a.setAttribute("type",b),c&&(a.value=c),b}}}}}),Za={set:function(a,b,c){return b===!1?n.removeAttr(a,c):a.setAttribute(c,c),c}},n.each(n.expr.match.bool.source.match(/\w+/g),function(a,b){var c=$a[b]||n.find.attr;$a[b]=function(a,b,d){var e,f;return d||(f=$a[b],$a[b]=e,e=null!=c(a,b,d)?b.toLowerCase():null,$a[b]=f),e}});var _a=/^(?:input|select|textarea|button)$/i;n.fn.extend({prop:function(a,b){return J(this,n.prop,a,b,arguments.length>1)},removeProp:function(a){return this.each(function(){delete this[n.propFix[a]||a]})}}),n.extend({propFix:{"for":"htmlFor","class":"className"},prop:function(a,b,c){var d,e,f,g=a.nodeType;if(a&&3!==g&&8!==g&&2!==g)return f=1!==g||!n.isXMLDoc(a),f&&(b=n.propFix[b]||b,e=n.propHooks[b]),void 0!==c?e&&"set"in e&&void 0!==(d=e.set(a,c,b))?d:a[b]=c:e&&"get"in e&&null!==(d=e.get(a,b))?d:a[b]},propHooks:{tabIndex:{get:function(a){return a.hasAttribute("tabindex")||_a.test(a.nodeName)||a.href?a.tabIndex:-1}}}}),k.optSelected||(n.propHooks.selected={get:function(a){var b=a.parentNode;return b&&b.parentNode&&b.parentNode.selectedIndex,null}}),n.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){n.propFix[this.toLowerCase()]=this});var ab=/[\t\r\n\f]/g;n.fn.extend({addClass:function(a){var b,c,d,e,f,g,h="string"==typeof a&&a,i=0,j=this.length;if(n.isFunction(a))return this.each(function(b){n(this).addClass(a.call(this,b,this.className))});if(h)for(b=(a||"").match(E)||[];j>i;i++)if(c=this[i],d=1===c.nodeType&&(c.className?(" "+c.className+" ").replace(ab," "):" ")){f=0;while(e=b[f++])d.indexOf(" "+e+" ")<0&&(d+=e+" ");g=n.trim(d),c.className!==g&&(c.className=g)}return this},removeClass:function(a){var b,c,d,e,f,g,h=0===arguments.length||"string"==typeof a&&a,i=0,j=this.length;if(n.isFunction(a))return this.each(function(b){n(this).removeClass(a.call(this,b,this.className))});if(h)for(b=(a||"").match(E)||[];j>i;i++)if(c=this[i],d=1===c.nodeType&&(c.className?(" "+c.className+" ").replace(ab," "):"")){f=0;while(e=b[f++])while(d.indexOf(" "+e+" ")>=0)d=d.replace(" "+e+" "," ");g=a?n.trim(d):"",c.className!==g&&(c.className=g)}return this},toggleClass:function(a,b){var c=typeof a;return"boolean"==typeof b&&"string"===c?b?this.addClass(a):this.removeClass(a):this.each(n.isFunction(a)?function(c){n(this).toggleClass(a.call(this,c,this.className,b),b)}:function(){if("string"===c){var b,d=0,e=n(this),f=a.match(E)||[];while(b=f[d++])e.hasClass(b)?e.removeClass(b):e.addClass(b)}else(c===U||"boolean"===c)&&(this.className&&L.set(this,"__className__",this.className),this.className=this.className||a===!1?"":L.get(this,"__className__")||"")})},hasClass:function(a){for(var b=" "+a+" ",c=0,d=this.length;d>c;c++)if(1===this[c].nodeType&&(" "+this[c].className+" ").replace(ab," ").indexOf(b)>=0)return!0;return!1}});var bb=/\r/g;n.fn.extend({val:function(a){var b,c,d,e=this[0];{if(arguments.length)return d=n.isFunction(a),this.each(function(c){var e;1===this.nodeType&&(e=d?a.call(this,c,n(this).val()):a,null==e?e="":"number"==typeof e?e+="":n.isArray(e)&&(e=n.map(e,function(a){return null==a?"":a+""})),b=n.valHooks[this.type]||n.valHooks[this.nodeName.toLowerCase()],b&&"set"in b&&void 0!==b.set(this,e,"value")||(this.value=e))});if(e)return b=n.valHooks[e.type]||n.valHooks[e.nodeName.toLowerCase()],b&&"get"in b&&void 0!==(c=b.get(e,"value"))?c:(c=e.value,"string"==typeof c?c.replace(bb,""):null==c?"":c)}}}),n.extend({valHooks:{option:{get:function(a){var b=n.find.attr(a,"value");return null!=b?b:n.trim(n.text(a))}},select:{get:function(a){for(var b,c,d=a.options,e=a.selectedIndex,f="select-one"===a.type||0>e,g=f?null:[],h=f?e+1:d.length,i=0>e?h:f?e:0;h>i;i++)if(c=d[i],!(!c.selected&&i!==e||(k.optDisabled?c.disabled:null!==c.getAttribute("disabled"))||c.parentNode.disabled&&n.nodeName(c.parentNode,"optgroup"))){if(b=n(c).val(),f)return b;g.push(b)}return g},set:function(a,b){var c,d,e=a.options,f=n.makeArray(b),g=e.length;while(g--)d=e[g],(d.selected=n.inArray(d.value,f)>=0)&&(c=!0);return c||(a.selectedIndex=-1),f}}}}),n.each(["radio","checkbox"],function(){n.valHooks[this]={set:function(a,b){return n.isArray(b)?a.checked=n.inArray(n(a).val(),b)>=0:void 0}},k.checkOn||(n.valHooks[this].get=function(a){return null===a.getAttribute("value")?"on":a.value})}),n.each("blur focus focusin focusout load resize scroll unload click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup error contextmenu".split(" "),function(a,b){n.fn[b]=function(a,c){return arguments.length>0?this.on(b,null,a,c):this.trigger(b)}}),n.fn.extend({hover:function(a,b){return this.mouseenter(a).mouseleave(b||a)},bind:function(a,b,c){return this.on(a,null,b,c)},unbind:function(a,b){return this.off(a,null,b)},delegate:function(a,b,c,d){return this.on(b,a,c,d)},undelegate:function(a,b,c){return 1===arguments.length?this.off(a,"**"):this.off(b,a||"**",c)}});var cb=n.now(),db=/\?/;n.parseJSON=function(a){return JSON.parse(a+"")},n.parseXML=function(a){var b,c;if(!a||"string"!=typeof a)return null;try{c=new DOMParser,b=c.parseFromString(a,"text/xml")}catch(d){b=void 0}return(!b||b.getElementsByTagName("parsererror").length)&&n.error("Invalid XML: "+a),b};var eb=/#.*$/,fb=/([?&])_=[^&]*/,gb=/^(.*?):[ \t]*([^\r\n]*)$/gm,hb=/^(?:about|app|app-storage|.+-extension|file|res|widget):$/,ib=/^(?:GET|HEAD)$/,jb=/^\/\//,kb=/^([\w.+-]+:)(?:\/\/(?:[^\/?#]*@|)([^\/?#:]*)(?::(\d+)|)|)/,lb={},mb={},nb="*/".concat("*"),ob=a.location.href,pb=kb.exec(ob.toLowerCase())||[];function qb(a){return function(b,c){"string"!=typeof b&&(c=b,b="*");var d,e=0,f=b.toLowerCase().match(E)||[];if(n.isFunction(c))while(d=f[e++])"+"===d[0]?(d=d.slice(1)||"*",(a[d]=a[d]||[]).unshift(c)):(a[d]=a[d]||[]).push(c)}}function rb(a,b,c,d){var e={},f=a===mb;function g(h){var i;return e[h]=!0,n.each(a[h]||[],function(a,h){var j=h(b,c,d);return"string"!=typeof j||f||e[j]?f?!(i=j):void 0:(b.dataTypes.unshift(j),g(j),!1)}),i}return g(b.dataTypes[0])||!e["*"]&&g("*")}function sb(a,b){var c,d,e=n.ajaxSettings.flatOptions||{};for(c in b)void 0!==b[c]&&((e[c]?a:d||(d={}))[c]=b[c]);return d&&n.extend(!0,a,d),a}function tb(a,b,c){var d,e,f,g,h=a.contents,i=a.dataTypes;while("*"===i[0])i.shift(),void 0===d&&(d=a.mimeType||b.getResponseHeader("Content-Type"));if(d)for(e in h)if(h[e]&&h[e].test(d)){i.unshift(e);break}if(i[0]in c)f=i[0];else{for(e in c){if(!i[0]||a.converters[e+" "+i[0]]){f=e;break}g||(g=e)}f=f||g}return f?(f!==i[0]&&i.unshift(f),c[f]):void 0}function ub(a,b,c,d){var e,f,g,h,i,j={},k=a.dataTypes.slice();if(k[1])for(g in a.converters)j[g.toLowerCase()]=a.converters[g];f=k.shift();while(f)if(a.responseFields[f]&&(c[a.responseFields[f]]=b),!i&&d&&a.dataFilter&&(b=a.dataFilter(b,a.dataType)),i=f,f=k.shift())if("*"===f)f=i;else if("*"!==i&&i!==f){if(g=j[i+" "+f]||j["* "+f],!g)for(e in j)if(h=e.split(" "),h[1]===f&&(g=j[i+" "+h[0]]||j["* "+h[0]])){g===!0?g=j[e]:j[e]!==!0&&(f=h[0],k.unshift(h[1]));break}if(g!==!0)if(g&&a["throws"])b=g(b);else try{b=g(b)}catch(l){return{state:"parsererror",error:g?l:"No conversion from "+i+" to "+f}}}return{state:"success",data:b}}n.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:ob,type:"GET",isLocal:hb.test(pb[1]),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":nb,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/xml/,html:/html/,json:/json/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":n.parseJSON,"text xml":n.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(a,b){return b?sb(sb(a,n.ajaxSettings),b):sb(n.ajaxSettings,a)},ajaxPrefilter:qb(lb),ajaxTransport:qb(mb),ajax:function(a,b){"object"==typeof a&&(b=a,a=void 0),b=b||{};var c,d,e,f,g,h,i,j,k=n.ajaxSetup({},b),l=k.context||k,m=k.context&&(l.nodeType||l.jquery)?n(l):n.event,o=n.Deferred(),p=n.Callbacks("once memory"),q=k.statusCode||{},r={},s={},t=0,u="canceled",v={readyState:0,getResponseHeader:function(a){var b;if(2===t){if(!f){f={};while(b=gb.exec(e))f[b[1].toLowerCase()]=b[2]}b=f[a.toLowerCase()]}return null==b?null:b},getAllResponseHeaders:function(){return 2===t?e:null},setRequestHeader:function(a,b){var c=a.toLowerCase();return t||(a=s[c]=s[c]||a,r[a]=b),this},overrideMimeType:function(a){return t||(k.mimeType=a),this},statusCode:function(a){var b;if(a)if(2>t)for(b in a)q[b]=[q[b],a[b]];else v.always(a[v.status]);return this},abort:function(a){var b=a||u;return c&&c.abort(b),x(0,b),this}};if(o.promise(v).complete=p.add,v.success=v.done,v.error=v.fail,k.url=((a||k.url||ob)+"").replace(eb,"").replace(jb,pb[1]+"//"),k.type=b.method||b.type||k.method||k.type,k.dataTypes=n.trim(k.dataType||"*").toLowerCase().match(E)||[""],null==k.crossDomain&&(h=kb.exec(k.url.toLowerCase()),k.crossDomain=!(!h||h[1]===pb[1]&&h[2]===pb[2]&&(h[3]||("http:"===h[1]?"80":"443"))===(pb[3]||("http:"===pb[1]?"80":"443")))),k.data&&k.processData&&"string"!=typeof k.data&&(k.data=n.param(k.data,k.traditional)),rb(lb,k,b,v),2===t)return v;i=n.event&&k.global,i&&0===n.active++&&n.event.trigger("ajaxStart"),k.type=k.type.toUpperCase(),k.hasContent=!ib.test(k.type),d=k.url,k.hasContent||(k.data&&(d=k.url+=(db.test(d)?"&":"?")+k.data,delete k.data),k.cache===!1&&(k.url=fb.test(d)?d.replace(fb,"$1_="+cb++):d+(db.test(d)?"&":"?")+"_="+cb++)),k.ifModified&&(n.lastModified[d]&&v.setRequestHeader("If-Modified-Since",n.lastModified[d]),n.etag[d]&&v.setRequestHeader("If-None-Match",n.etag[d])),(k.data&&k.hasContent&&k.contentType!==!1||b.contentType)&&v.setRequestHeader("Content-Type",k.contentType),v.setRequestHeader("Accept",k.dataTypes[0]&&k.accepts[k.dataTypes[0]]?k.accepts[k.dataTypes[0]]+("*"!==k.dataTypes[0]?", "+nb+"; q=0.01":""):k.accepts["*"]);for(j in k.headers)v.setRequestHeader(j,k.headers[j]);if(k.beforeSend&&(k.beforeSend.call(l,v,k)===!1||2===t))return v.abort();u="abort";for(j in{success:1,error:1,complete:1})v[j](k[j]);if(c=rb(mb,k,b,v)){v.readyState=1,i&&m.trigger("ajaxSend",[v,k]),k.async&&k.timeout>0&&(g=setTimeout(function(){v.abort("timeout")},k.timeout));try{t=1,c.send(r,x)}catch(w){if(!(2>t))throw w;x(-1,w)}}else x(-1,"No Transport");function x(a,b,f,h){var j,r,s,u,w,x=b;2!==t&&(t=2,g&&clearTimeout(g),c=void 0,e=h||"",v.readyState=a>0?4:0,j=a>=200&&300>a||304===a,f&&(u=tb(k,v,f)),u=ub(k,u,v,j),j?(k.ifModified&&(w=v.getResponseHeader("Last-Modified"),w&&(n.lastModified[d]=w),w=v.getResponseHeader("etag"),w&&(n.etag[d]=w)),204===a||"HEAD"===k.type?x="nocontent":304===a?x="notmodified":(x=u.state,r=u.data,s=u.error,j=!s)):(s=x,(a||!x)&&(x="error",0>a&&(a=0))),v.status=a,v.statusText=(b||x)+"",j?o.resolveWith(l,[r,x,v]):o.rejectWith(l,[v,x,s]),v.statusCode(q),q=void 0,i&&m.trigger(j?"ajaxSuccess":"ajaxError",[v,k,j?r:s]),p.fireWith(l,[v,x]),i&&(m.trigger("ajaxComplete",[v,k]),--n.active||n.event.trigger("ajaxStop")))}return v},getJSON:function(a,b,c){return n.get(a,b,c,"json")},getScript:function(a,b){return n.get(a,void 0,b,"script")}}),n.each(["get","post"],function(a,b){n[b]=function(a,c,d,e){return n.isFunction(c)&&(e=e||d,d=c,c=void 0),n.ajax({url:a,type:b,dataType:e,data:c,success:d})}}),n._evalUrl=function(a){return n.ajax({url:a,type:"GET",dataType:"script",async:!1,global:!1,"throws":!0})},n.fn.extend({wrapAll:function(a){var b;return n.isFunction(a)?this.each(function(b){n(this).wrapAll(a.call(this,b))}):(this[0]&&(b=n(a,this[0].ownerDocument).eq(0).clone(!0),this[0].parentNode&&b.insertBefore(this[0]),b.map(function(){var a=this;while(a.firstElementChild)a=a.firstElementChild;return a}).append(this)),this)},wrapInner:function(a){return this.each(n.isFunction(a)?function(b){n(this).wrapInner(a.call(this,b))}:function(){var b=n(this),c=b.contents();c.length?c.wrapAll(a):b.append(a)})},wrap:function(a){var b=n.isFunction(a);return this.each(function(c){n(this).wrapAll(b?a.call(this,c):a)})},unwrap:function(){return this.parent().each(function(){n.nodeName(this,"body")||n(this).replaceWith(this.childNodes)}).end()}}),n.expr.filters.hidden=function(a){return a.offsetWidth<=0&&a.offsetHeight<=0},n.expr.filters.visible=function(a){return!n.expr.filters.hidden(a)};var vb=/%20/g,wb=/\[\]$/,xb=/\r?\n/g,yb=/^(?:submit|button|image|reset|file)$/i,zb=/^(?:input|select|textarea|keygen)/i;function Ab(a,b,c,d){var e;if(n.isArray(b))n.each(b,function(b,e){c||wb.test(a)?d(a,e):Ab(a+"["+("object"==typeof e?b:"")+"]",e,c,d)});else if(c||"object"!==n.type(b))d(a,b);else for(e in b)Ab(a+"["+e+"]",b[e],c,d)}n.param=function(a,b){var c,d=[],e=function(a,b){b=n.isFunction(b)?b():null==b?"":b,d[d.length]=encodeURIComponent(a)+"="+encodeURIComponent(b)};if(void 0===b&&(b=n.ajaxSettings&&n.ajaxSettings.traditional),n.isArray(a)||a.jquery&&!n.isPlainObject(a))n.each(a,function(){e(this.name,this.value)});else for(c in a)Ab(c,a[c],b,e);return d.join("&").replace(vb,"+")},n.fn.extend({serialize:function(){return n.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var a=n.prop(this,"elements");return a?n.makeArray(a):this}).filter(function(){var a=this.type;return this.name&&!n(this).is(":disabled")&&zb.test(this.nodeName)&&!yb.test(a)&&(this.checked||!T.test(a))}).map(function(a,b){var c=n(this).val();return null==c?null:n.isArray(c)?n.map(c,function(a){return{name:b.name,value:a.replace(xb,"\r\n")}}):{name:b.name,value:c.replace(xb,"\r\n")}}).get()}}),n.ajaxSettings.xhr=function(){try{return new XMLHttpRequest}catch(a){}};var Bb=0,Cb={},Db={0:200,1223:204},Eb=n.ajaxSettings.xhr();a.attachEvent&&a.attachEvent("onunload",function(){for(var a in Cb)Cb[a]()}),k.cors=!!Eb&&"withCredentials"in Eb,k.ajax=Eb=!!Eb,n.ajaxTransport(function(a){var b;return k.cors||Eb&&!a.crossDomain?{send:function(c,d){var e,f=a.xhr(),g=++Bb;if(f.open(a.type,a.url,a.async,a.username,a.password),a.xhrFields)for(e in a.xhrFields)f[e]=a.xhrFields[e];a.mimeType&&f.overrideMimeType&&f.overrideMimeType(a.mimeType),a.crossDomain||c["X-Requested-With"]||(c["X-Requested-With"]="XMLHttpRequest");for(e in c)f.setRequestHeader(e,c[e]);b=function(a){return function(){b&&(delete Cb[g],b=f.onload=f.onerror=null,"abort"===a?f.abort():"error"===a?d(f.status,f.statusText):d(Db[f.status]||f.status,f.statusText,"string"==typeof f.responseText?{text:f.responseText}:void 0,f.getAllResponseHeaders()))}},f.onload=b(),f.onerror=b("error"),b=Cb[g]=b("abort");try{f.send(a.hasContent&&a.data||null)}catch(h){if(b)throw h}},abort:function(){b&&b()}}:void 0}),n.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/(?:java|ecma)script/},converters:{"text script":function(a){return n.globalEval(a),a}}}),n.ajaxPrefilter("script",function(a){void 0===a.cache&&(a.cache=!1),a.crossDomain&&(a.type="GET")}),n.ajaxTransport("script",function(a){if(a.crossDomain){var b,c;return{send:function(d,e){b=n("<script>").prop({async:!0,charset:a.scriptCharset,src:a.url}).on("load error",c=function(a){b.remove(),c=null,a&&e("error"===a.type?404:200,a.type)}),l.head.appendChild(b[0])},abort:function(){c&&c()}}}});var Fb=[],Gb=/(=)\?(?=&|$)|\?\?/;n.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var a=Fb.pop()||n.expando+"_"+cb++;return this[a]=!0,a}}),n.ajaxPrefilter("json jsonp",function(b,c,d){var e,f,g,h=b.jsonp!==!1&&(Gb.test(b.url)?"url":"string"==typeof b.data&&!(b.contentType||"").indexOf("application/x-www-form-urlencoded")&&Gb.test(b.data)&&"data");return h||"jsonp"===b.dataTypes[0]?(e=b.jsonpCallback=n.isFunction(b.jsonpCallback)?b.jsonpCallback():b.jsonpCallback,h?b[h]=b[h].replace(Gb,"$1"+e):b.jsonp!==!1&&(b.url+=(db.test(b.url)?"&":"?")+b.jsonp+"="+e),b.converters["script json"]=function(){return g||n.error(e+" was not called"),g[0]},b.dataTypes[0]="json",f=a[e],a[e]=function(){g=arguments},d.always(function(){a[e]=f,b[e]&&(b.jsonpCallback=c.jsonpCallback,Fb.push(e)),g&&n.isFunction(f)&&f(g[0]),g=f=void 0}),"script"):void 0}),n.parseHTML=function(a,b,c){if(!a||"string"!=typeof a)return null;"boolean"==typeof b&&(c=b,b=!1),b=b||l;var d=v.exec(a),e=!c&&[];return d?[b.createElement(d[1])]:(d=n.buildFragment([a],b,e),e&&e.length&&n(e).remove(),n.merge([],d.childNodes))};var Hb=n.fn.load;n.fn.load=function(a,b,c){if("string"!=typeof a&&Hb)return Hb.apply(this,arguments);var d,e,f,g=this,h=a.indexOf(" ");return h>=0&&(d=n.trim(a.slice(h)),a=a.slice(0,h)),n.isFunction(b)?(c=b,b=void 0):b&&"object"==typeof b&&(e="POST"),g.length>0&&n.ajax({url:a,type:e,dataType:"html",data:b}).done(function(a){f=arguments,g.html(d?n("<div>").append(n.parseHTML(a)).find(d):a)}).complete(c&&function(a,b){g.each(c,f||[a.responseText,b,a])}),this},n.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(a,b){n.fn[b]=function(a){return this.on(b,a)}}),n.expr.filters.animated=function(a){return n.grep(n.timers,function(b){return a===b.elem}).length};var Ib=a.document.documentElement;function Jb(a){return n.isWindow(a)?a:9===a.nodeType&&a.defaultView}n.offset={setOffset:function(a,b,c){var d,e,f,g,h,i,j,k=n.css(a,"position"),l=n(a),m={};"static"===k&&(a.style.position="relative"),h=l.offset(),f=n.css(a,"top"),i=n.css(a,"left"),j=("absolute"===k||"fixed"===k)&&(f+i).indexOf("auto")>-1,j?(d=l.position(),g=d.top,e=d.left):(g=parseFloat(f)||0,e=parseFloat(i)||0),n.isFunction(b)&&(b=b.call(a,c,h)),null!=b.top&&(m.top=b.top-h.top+g),null!=b.left&&(m.left=b.left-h.left+e),"using"in b?b.using.call(a,m):l.css(m)}},n.fn.extend({offset:function(a){if(arguments.length)return void 0===a?this:this.each(function(b){n.offset.setOffset(this,a,b)});var b,c,d=this[0],e={top:0,left:0},f=d&&d.ownerDocument;if(f)return b=f.documentElement,n.contains(b,d)?(typeof d.getBoundingClientRect!==U&&(e=d.getBoundingClientRect()),c=Jb(f),{top:e.top+c.pageYOffset-b.clientTop,left:e.left+c.pageXOffset-b.clientLeft}):e},position:function(){if(this[0]){var a,b,c=this[0],d={top:0,left:0};return"fixed"===n.css(c,"position")?b=c.getBoundingClientRect():(a=this.offsetParent(),b=this.offset(),n.nodeName(a[0],"html")||(d=a.offset()),d.top+=n.css(a[0],"borderTopWidth",!0),d.left+=n.css(a[0],"borderLeftWidth",!0)),{top:b.top-d.top-n.css(c,"marginTop",!0),left:b.left-d.left-n.css(c,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var a=this.offsetParent||Ib;while(a&&!n.nodeName(a,"html")&&"static"===n.css(a,"position"))a=a.offsetParent;return a||Ib})}}),n.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(b,c){var d="pageYOffset"===c;n.fn[b]=function(e){return J(this,function(b,e,f){var g=Jb(b);return void 0===f?g?g[c]:b[e]:void(g?g.scrollTo(d?a.pageXOffset:f,d?f:a.pageYOffset):b[e]=f)},b,e,arguments.length,null)}}),n.each(["top","left"],function(a,b){n.cssHooks[b]=ya(k.pixelPosition,function(a,c){return c?(c=xa(a,b),va.test(c)?n(a).position()[b]+"px":c):void 0})}),n.each({Height:"height",Width:"width"},function(a,b){n.each({padding:"inner"+a,content:b,"":"outer"+a},function(c,d){n.fn[d]=function(d,e){var f=arguments.length&&(c||"boolean"!=typeof d),g=c||(d===!0||e===!0?"margin":"border");return J(this,function(b,c,d){var e;return n.isWindow(b)?b.document.documentElement["client"+a]:9===b.nodeType?(e=b.documentElement,Math.max(b.body["scroll"+a],e["scroll"+a],b.body["offset"+a],e["offset"+a],e["client"+a])):void 0===d?n.css(b,c,g):n.style(b,c,d,g)},b,f?d:void 0,f,null)}})}),n.fn.size=function(){return this.length},n.fn.andSelf=n.fn.addBack,"function"==typeof define&&define.amd&&define("jquery",[],function(){return n});var Kb=a.jQuery,Lb=a.$;return n.noConflict=function(b){return a.$===n&&(a.$=Lb),b&&a.jQuery===n&&(a.jQuery=Kb),n},typeof b===U&&(a.jQuery=a.$=n),n});
-//# sourceMappingURL=jquery.min.map
\ No newline at end of file
+/*! jQuery v3.6.4 | (c) OpenJS Foundation and other contributors | jquery.org/license */
+!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(C,e){"use strict";var t=[],r=Object.getPrototypeOf,s=t.slice,g=t.flat?function(e){return t.flat.call(e)}:function(e){return t.concat.apply([],e)},u=t.push,i=t.indexOf,n={},o=n.toString,y=n.hasOwnProperty,a=y.toString,l=a.call(Object),v={},m=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType&&"function"!=typeof e.item},x=function(e){return null!=e&&e===e.window},E=C.document,c={type:!0,src:!0,nonce:!0,noModule:!0};function b(e,t,n){var r,i,o=(n=n||E).createElement("script");if(o.text=e,t)for(r in c)(i=t[r]||t.getAttribute&&t.getAttribute(r))&&o.setAttribute(r,i);n.head.appendChild(o).parentNode.removeChild(o)}function w(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?n[o.call(e)]||"object":typeof e}var f="3.6.4",S=function(e,t){return new S.fn.init(e,t)};function p(e){var t=!!e&&"length"in e&&e.length,n=w(e);return!m(e)&&!x(e)&&("array"===n||0===t||"number"==typeof t&&0<t&&t-1 in e)}S.fn=S.prototype={jquery:f,constructor:S,length:0,toArray:function(){return s.call(this)},get:function(e){return null==e?s.call(this):e<0?this[e+this.length]:this[e]},pushStack:function(e){var t=S.merge(this.constructor(),e);return t.prevObject=this,t},each:function(e){return S.each(this,e)},map:function(n){return this.pushStack(S.map(this,function(e,t){return n.call(e,t,e)}))},slice:function(){return this.pushStack(s.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},even:function(){return this.pushStack(S.grep(this,function(e,t){return(t+1)%2}))},odd:function(){return this.pushStack(S.grep(this,function(e,t){return t%2}))},eq:function(e){var t=this.length,n=+e+(e<0?t:0);return this.pushStack(0<=n&&n<t?[this[n]]:[])},end:function(){return this.prevObject||this.constructor()},push:u,sort:t.sort,splice:t.splice},S.extend=S.fn.extend=function(){var e,t,n,r,i,o,a=arguments[0]||{},s=1,u=arguments.length,l=!1;for("boolean"==typeof a&&(l=a,a=arguments[s]||{},s++),"object"==typeof a||m(a)||(a={}),s===u&&(a=this,s--);s<u;s++)if(null!=(e=arguments[s]))for(t in e)r=e[t],"__proto__"!==t&&a!==r&&(l&&r&&(S.isPlainObject(r)||(i=Array.isArray(r)))?(n=a[t],o=i&&!Array.isArray(n)?[]:i||S.isPlainObject(n)?n:{},i=!1,a[t]=S.extend(l,o,r)):void 0!==r&&(a[t]=r));return a},S.extend({expando:"jQuery"+(f+Math.random()).replace(/\D/g,""),isReady:!0,error:function(e){throw new Error(e)},noop:function(){},isPlainObject:function(e){var t,n;return!(!e||"[object Object]"!==o.call(e))&&(!(t=r(e))||"function"==typeof(n=y.call(t,"constructor")&&t.constructor)&&a.call(n)===l)},isEmptyObject:function(e){var t;for(t in e)return!1;return!0},globalEval:function(e,t,n){b(e,{nonce:t&&t.nonce},n)},each:function(e,t){var n,r=0;if(p(e)){for(n=e.length;r<n;r++)if(!1===t.call(e[r],r,e[r]))break}else for(r in e)if(!1===t.call(e[r],r,e[r]))break;return e},makeArray:function(e,t){var n=t||[];return null!=e&&(p(Object(e))?S.merge(n,"string"==typeof e?[e]:e):u.call(n,e)),n},inArray:function(e,t,n){return null==t?-1:i.call(t,e,n)},merge:function(e,t){for(var n=+t.length,r=0,i=e.length;r<n;r++)e[i++]=t[r];return e.length=i,e},grep:function(e,t,n){for(var r=[],i=0,o=e.length,a=!n;i<o;i++)!t(e[i],i)!==a&&r.push(e[i]);return r},map:function(e,t,n){var r,i,o=0,a=[];if(p(e))for(r=e.length;o<r;o++)null!=(i=t(e[o],o,n))&&a.push(i);else for(o in e)null!=(i=t(e[o],o,n))&&a.push(i);return g(a)},guid:1,support:v}),"function"==typeof Symbol&&(S.fn[Symbol.iterator]=t[Symbol.iterator]),S.each("Boolean Number String Function Array Date RegExp Object Error Symbol".split(" "),function(e,t){n["[object "+t+"]"]=t.toLowerCase()});var d=function(n){var e,d,b,o,i,h,f,g,w,u,l,T,C,a,E,y,s,c,v,S="sizzle"+1*new Date,p=n.document,k=0,r=0,m=ue(),x=ue(),A=ue(),N=ue(),j=function(e,t){return e===t&&(l=!0),0},D={}.hasOwnProperty,t=[],q=t.pop,L=t.push,H=t.push,O=t.slice,P=function(e,t){for(var n=0,r=e.length;n<r;n++)if(e[n]===t)return n;return-1},R="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",M="[\\x20\\t\\r\\n\\f]",I="(?:\\\\[\\da-fA-F]{1,6}"+M+"?|\\\\[^\\r\\n\\f]|[\\w-]|[^\0-\\x7f])+",W="\\["+M+"*("+I+")(?:"+M+"*([*^$|!~]?=)"+M+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+I+"))|)"+M+"*\\]",F=":("+I+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+W+")*)|.*)\\)|)",$=new RegExp(M+"+","g"),B=new RegExp("^"+M+"+|((?:^|[^\\\\])(?:\\\\.)*)"+M+"+$","g"),_=new RegExp("^"+M+"*,"+M+"*"),z=new RegExp("^"+M+"*([>+~]|"+M+")"+M+"*"),U=new RegExp(M+"|>"),X=new RegExp(F),V=new RegExp("^"+I+"$"),G={ID:new RegExp("^#("+I+")"),CLASS:new RegExp("^\\.("+I+")"),TAG:new RegExp("^("+I+"|[*])"),ATTR:new RegExp("^"+W),PSEUDO:new RegExp("^"+F),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+M+"*(even|odd|(([+-]|)(\\d*)n|)"+M+"*(?:([+-]|)"+M+"*(\\d+)|))"+M+"*\\)|)","i"),bool:new RegExp("^(?:"+R+")$","i"),needsContext:new RegExp("^"+M+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+M+"*((?:-\\d)?\\d*)"+M+"*\\)|)(?=[^-]|$)","i")},Y=/HTML$/i,Q=/^(?:input|select|textarea|button)$/i,J=/^h\d$/i,K=/^[^{]+\{\s*\[native \w/,Z=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,ee=/[+~]/,te=new RegExp("\\\\[\\da-fA-F]{1,6}"+M+"?|\\\\([^\\r\\n\\f])","g"),ne=function(e,t){var n="0x"+e.slice(1)-65536;return t||(n<0?String.fromCharCode(n+65536):String.fromCharCode(n>>10|55296,1023&n|56320))},re=/([\0-\x1f\x7f]|^-?\d)|^-$|[^\0-\x1f\x7f-\uFFFF\w-]/g,ie=function(e,t){return t?"\0"===e?"\ufffd":e.slice(0,-1)+"\\"+e.charCodeAt(e.length-1).toString(16)+" ":"\\"+e},oe=function(){T()},ae=be(function(e){return!0===e.disabled&&"fieldset"===e.nodeName.toLowerCase()},{dir:"parentNode",next:"legend"});try{H.apply(t=O.call(p.childNodes),p.childNodes),t[p.childNodes.length].nodeType}catch(e){H={apply:t.length?function(e,t){L.apply(e,O.call(t))}:function(e,t){var n=e.length,r=0;while(e[n++]=t[r++]);e.length=n-1}}}function se(t,e,n,r){var i,o,a,s,u,l,c,f=e&&e.ownerDocument,p=e?e.nodeType:9;if(n=n||[],"string"!=typeof t||!t||1!==p&&9!==p&&11!==p)return n;if(!r&&(T(e),e=e||C,E)){if(11!==p&&(u=Z.exec(t)))if(i=u[1]){if(9===p){if(!(a=e.getElementById(i)))return n;if(a.id===i)return n.push(a),n}else if(f&&(a=f.getElementById(i))&&v(e,a)&&a.id===i)return n.push(a),n}else{if(u[2])return H.apply(n,e.getElementsByTagName(t)),n;if((i=u[3])&&d.getElementsByClassName&&e.getElementsByClassName)return H.apply(n,e.getElementsByClassName(i)),n}if(d.qsa&&!N[t+" "]&&(!y||!y.test(t))&&(1!==p||"object"!==e.nodeName.toLowerCase())){if(c=t,f=e,1===p&&(U.test(t)||z.test(t))){(f=ee.test(t)&&ve(e.parentNode)||e)===e&&d.scope||((s=e.getAttribute("id"))?s=s.replace(re,ie):e.setAttribute("id",s=S)),o=(l=h(t)).length;while(o--)l[o]=(s?"#"+s:":scope")+" "+xe(l[o]);c=l.join(",")}try{return H.apply(n,f.querySelectorAll(c)),n}catch(e){N(t,!0)}finally{s===S&&e.removeAttribute("id")}}}return g(t.replace(B,"$1"),e,n,r)}function ue(){var r=[];return function e(t,n){return r.push(t+" ")>b.cacheLength&&delete e[r.shift()],e[t+" "]=n}}function le(e){return e[S]=!0,e}function ce(e){var t=C.createElement("fieldset");try{return!!e(t)}catch(e){return!1}finally{t.parentNode&&t.parentNode.removeChild(t),t=null}}function fe(e,t){var n=e.split("|"),r=n.length;while(r--)b.attrHandle[n[r]]=t}function pe(e,t){var n=t&&e,r=n&&1===e.nodeType&&1===t.nodeType&&e.sourceIndex-t.sourceIndex;if(r)return r;if(n)while(n=n.nextSibling)if(n===t)return-1;return e?1:-1}function de(t){return function(e){return"input"===e.nodeName.toLowerCase()&&e.type===t}}function he(n){return function(e){var t=e.nodeName.toLowerCase();return("input"===t||"button"===t)&&e.type===n}}function ge(t){return function(e){return"form"in e?e.parentNode&&!1===e.disabled?"label"in e?"label"in e.parentNode?e.parentNode.disabled===t:e.disabled===t:e.isDisabled===t||e.isDisabled!==!t&&ae(e)===t:e.disabled===t:"label"in e&&e.disabled===t}}function ye(a){return le(function(o){return o=+o,le(function(e,t){var n,r=a([],e.length,o),i=r.length;while(i--)e[n=r[i]]&&(e[n]=!(t[n]=e[n]))})})}function ve(e){return e&&"undefined"!=typeof e.getElementsByTagName&&e}for(e in d=se.support={},i=se.isXML=function(e){var t=e&&e.namespaceURI,n=e&&(e.ownerDocument||e).documentElement;return!Y.test(t||n&&n.nodeName||"HTML")},T=se.setDocument=function(e){var t,n,r=e?e.ownerDocument||e:p;return r!=C&&9===r.nodeType&&r.documentElement&&(a=(C=r).documentElement,E=!i(C),p!=C&&(n=C.defaultView)&&n.top!==n&&(n.addEventListener?n.addEventListener("unload",oe,!1):n.attachEvent&&n.attachEvent("onunload",oe)),d.scope=ce(function(e){return a.appendChild(e).appendChild(C.createElement("div")),"undefined"!=typeof e.querySelectorAll&&!e.querySelectorAll(":scope fieldset div").length}),d.cssHas=ce(function(){try{return C.querySelector(":has(*,:jqfake)"),!1}catch(e){return!0}}),d.attributes=ce(function(e){return e.className="i",!e.getAttribute("className")}),d.getElementsByTagName=ce(function(e){return e.appendChild(C.createComment("")),!e.getElementsByTagName("*").length}),d.getElementsByClassName=K.test(C.getElementsByClassName),d.getById=ce(function(e){return a.appendChild(e).id=S,!C.getElementsByName||!C.getElementsByName(S).length}),d.getById?(b.filter.ID=function(e){var t=e.replace(te,ne);return function(e){return e.getAttribute("id")===t}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n=t.getElementById(e);return n?[n]:[]}}):(b.filter.ID=function(e){var n=e.replace(te,ne);return function(e){var t="undefined"!=typeof e.getAttributeNode&&e.getAttributeNode("id");return t&&t.value===n}},b.find.ID=function(e,t){if("undefined"!=typeof t.getElementById&&E){var n,r,i,o=t.getElementById(e);if(o){if((n=o.getAttributeNode("id"))&&n.value===e)return[o];i=t.getElementsByName(e),r=0;while(o=i[r++])if((n=o.getAttributeNode("id"))&&n.value===e)return[o]}return[]}}),b.find.TAG=d.getElementsByTagName?function(e,t){return"undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e):d.qsa?t.querySelectorAll(e):void 0}:function(e,t){var n,r=[],i=0,o=t.getElementsByTagName(e);if("*"===e){while(n=o[i++])1===n.nodeType&&r.push(n);return r}return o},b.find.CLASS=d.getElementsByClassName&&function(e,t){if("undefined"!=typeof t.getElementsByClassName&&E)return t.getElementsByClassName(e)},s=[],y=[],(d.qsa=K.test(C.querySelectorAll))&&(ce(function(e){var t;a.appendChild(e).innerHTML="<a id='"+S+"'></a><select id='"+S+"-\r\\' msallowcapture=''><option selected=''></option></select>",e.querySelectorAll("[msallowcapture^='']").length&&y.push("[*^$]="+M+"*(?:''|\"\")"),e.querySelectorAll("[selected]").length||y.push("\\["+M+"*(?:value|"+R+")"),e.querySelectorAll("[id~="+S+"-]").length||y.push("~="),(t=C.createElement("input")).setAttribute("name",""),e.appendChild(t),e.querySelectorAll("[name='']").length||y.push("\\["+M+"*name"+M+"*="+M+"*(?:''|\"\")"),e.querySelectorAll(":checked").length||y.push(":checked"),e.querySelectorAll("a#"+S+"+*").length||y.push(".#.+[+~]"),e.querySelectorAll("\\\f"),y.push("[\\r\\n\\f]")}),ce(function(e){e.innerHTML="<a href='' disabled='disabled'></a><select disabled='disabled'><option/></select>";var t=C.createElement("input");t.setAttribute("type","hidden"),e.appendChild(t).setAttribute("name","D"),e.querySelectorAll("[name=d]").length&&y.push("name"+M+"*[*^$|!~]?="),2!==e.querySelectorAll(":enabled").length&&y.push(":enabled",":disabled"),a.appendChild(e).disabled=!0,2!==e.querySelectorAll(":disabled").length&&y.push(":enabled",":disabled"),e.querySelectorAll("*,:x"),y.push(",.*:")})),(d.matchesSelector=K.test(c=a.matches||a.webkitMatchesSelector||a.mozMatchesSelector||a.oMatchesSelector||a.msMatchesSelector))&&ce(function(e){d.disconnectedMatch=c.call(e,"*"),c.call(e,"[s!='']:x"),s.push("!=",F)}),d.cssHas||y.push(":has"),y=y.length&&new RegExp(y.join("|")),s=s.length&&new RegExp(s.join("|")),t=K.test(a.compareDocumentPosition),v=t||K.test(a.contains)?function(e,t){var n=9===e.nodeType&&e.documentElement||e,r=t&&t.parentNode;return e===r||!(!r||1!==r.nodeType||!(n.contains?n.contains(r):e.compareDocumentPosition&&16&e.compareDocumentPosition(r)))}:function(e,t){if(t)while(t=t.parentNode)if(t===e)return!0;return!1},j=t?function(e,t){if(e===t)return l=!0,0;var n=!e.compareDocumentPosition-!t.compareDocumentPosition;return n||(1&(n=(e.ownerDocument||e)==(t.ownerDocument||t)?e.compareDocumentPosition(t):1)||!d.sortDetached&&t.compareDocumentPosition(e)===n?e==C||e.ownerDocument==p&&v(p,e)?-1:t==C||t.ownerDocument==p&&v(p,t)?1:u?P(u,e)-P(u,t):0:4&n?-1:1)}:function(e,t){if(e===t)return l=!0,0;var n,r=0,i=e.parentNode,o=t.parentNode,a=[e],s=[t];if(!i||!o)return e==C?-1:t==C?1:i?-1:o?1:u?P(u,e)-P(u,t):0;if(i===o)return pe(e,t);n=e;while(n=n.parentNode)a.unshift(n);n=t;while(n=n.parentNode)s.unshift(n);while(a[r]===s[r])r++;return r?pe(a[r],s[r]):a[r]==p?-1:s[r]==p?1:0}),C},se.matches=function(e,t){return se(e,null,null,t)},se.matchesSelector=function(e,t){if(T(e),d.matchesSelector&&E&&!N[t+" "]&&(!s||!s.test(t))&&(!y||!y.test(t)))try{var n=c.call(e,t);if(n||d.disconnectedMatch||e.document&&11!==e.document.nodeType)return n}catch(e){N(t,!0)}return 0<se(t,C,null,[e]).length},se.contains=function(e,t){return(e.ownerDocument||e)!=C&&T(e),v(e,t)},se.attr=function(e,t){(e.ownerDocument||e)!=C&&T(e);var n=b.attrHandle[t.toLowerCase()],r=n&&D.call(b.attrHandle,t.toLowerCase())?n(e,t,!E):void 0;return void 0!==r?r:d.attributes||!E?e.getAttribute(t):(r=e.getAttributeNode(t))&&r.specified?r.value:null},se.escape=function(e){return(e+"").replace(re,ie)},se.error=function(e){throw new Error("Syntax error, unrecognized expression: "+e)},se.uniqueSort=function(e){var t,n=[],r=0,i=0;if(l=!d.detectDuplicates,u=!d.sortStable&&e.slice(0),e.sort(j),l){while(t=e[i++])t===e[i]&&(r=n.push(i));while(r--)e.splice(n[r],1)}return u=null,e},o=se.getText=function(e){var t,n="",r=0,i=e.nodeType;if(i){if(1===i||9===i||11===i){if("string"==typeof e.textContent)return e.textContent;for(e=e.firstChild;e;e=e.nextSibling)n+=o(e)}else if(3===i||4===i)return e.nodeValue}else while(t=e[r++])n+=o(t);return n},(b=se.selectors={cacheLength:50,createPseudo:le,match:G,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(e){return e[1]=e[1].replace(te,ne),e[3]=(e[3]||e[4]||e[5]||"").replace(te,ne),"~="===e[2]&&(e[3]=" "+e[3]+" "),e.slice(0,4)},CHILD:function(e){return e[1]=e[1].toLowerCase(),"nth"===e[1].slice(0,3)?(e[3]||se.error(e[0]),e[4]=+(e[4]?e[5]+(e[6]||1):2*("even"===e[3]||"odd"===e[3])),e[5]=+(e[7]+e[8]||"odd"===e[3])):e[3]&&se.error(e[0]),e},PSEUDO:function(e){var t,n=!e[6]&&e[2];return G.CHILD.test(e[0])?null:(e[3]?e[2]=e[4]||e[5]||"":n&&X.test(n)&&(t=h(n,!0))&&(t=n.indexOf(")",n.length-t)-n.length)&&(e[0]=e[0].slice(0,t),e[2]=n.slice(0,t)),e.slice(0,3))}},filter:{TAG:function(e){var t=e.replace(te,ne).toLowerCase();return"*"===e?function(){return!0}:function(e){return e.nodeName&&e.nodeName.toLowerCase()===t}},CLASS:function(e){var t=m[e+" "];return t||(t=new RegExp("(^|"+M+")"+e+"("+M+"|$)"))&&m(e,function(e){return t.test("string"==typeof e.className&&e.className||"undefined"!=typeof e.getAttribute&&e.getAttribute("class")||"")})},ATTR:function(n,r,i){return function(e){var t=se.attr(e,n);return null==t?"!="===r:!r||(t+="","="===r?t===i:"!="===r?t!==i:"^="===r?i&&0===t.indexOf(i):"*="===r?i&&-1<t.indexOf(i):"$="===r?i&&t.slice(-i.length)===i:"~="===r?-1<(" "+t.replace($," ")+" ").indexOf(i):"|="===r&&(t===i||t.slice(0,i.length+1)===i+"-"))}},CHILD:function(h,e,t,g,y){var v="nth"!==h.slice(0,3),m="last"!==h.slice(-4),x="of-type"===e;return 1===g&&0===y?function(e){return!!e.parentNode}:function(e,t,n){var r,i,o,a,s,u,l=v!==m?"nextSibling":"previousSibling",c=e.parentNode,f=x&&e.nodeName.toLowerCase(),p=!n&&!x,d=!1;if(c){if(v){while(l){a=e;while(a=a[l])if(x?a.nodeName.toLowerCase()===f:1===a.nodeType)return!1;u=l="only"===h&&!u&&"nextSibling"}return!0}if(u=[m?c.firstChild:c.lastChild],m&&p){d=(s=(r=(i=(o=(a=c)[S]||(a[S]={}))[a.uniqueID]||(o[a.uniqueID]={}))[h]||[])[0]===k&&r[1])&&r[2],a=s&&c.childNodes[s];while(a=++s&&a&&a[l]||(d=s=0)||u.pop())if(1===a.nodeType&&++d&&a===e){i[h]=[k,s,d];break}}else if(p&&(d=s=(r=(i=(o=(a=e)[S]||(a[S]={}))[a.uniqueID]||(o[a.uniqueID]={}))[h]||[])[0]===k&&r[1]),!1===d)while(a=++s&&a&&a[l]||(d=s=0)||u.pop())if((x?a.nodeName.toLowerCase()===f:1===a.nodeType)&&++d&&(p&&((i=(o=a[S]||(a[S]={}))[a.uniqueID]||(o[a.uniqueID]={}))[h]=[k,d]),a===e))break;return(d-=y)===g||d%g==0&&0<=d/g}}},PSEUDO:function(e,o){var t,a=b.pseudos[e]||b.setFilters[e.toLowerCase()]||se.error("unsupported pseudo: "+e);return a[S]?a(o):1<a.length?(t=[e,e,"",o],b.setFilters.hasOwnProperty(e.toLowerCase())?le(function(e,t){var n,r=a(e,o),i=r.length;while(i--)e[n=P(e,r[i])]=!(t[n]=r[i])}):function(e){return a(e,0,t)}):a}},pseudos:{not:le(function(e){var r=[],i=[],s=f(e.replace(B,"$1"));return s[S]?le(function(e,t,n,r){var i,o=s(e,null,r,[]),a=e.length;while(a--)(i=o[a])&&(e[a]=!(t[a]=i))}):function(e,t,n){return r[0]=e,s(r,null,n,i),r[0]=null,!i.pop()}}),has:le(function(t){return function(e){return 0<se(t,e).length}}),contains:le(function(t){return t=t.replace(te,ne),function(e){return-1<(e.textContent||o(e)).indexOf(t)}}),lang:le(function(n){return V.test(n||"")||se.error("unsupported lang: "+n),n=n.replace(te,ne).toLowerCase(),function(e){var t;do{if(t=E?e.lang:e.getAttribute("xml:lang")||e.getAttribute("lang"))return(t=t.toLowerCase())===n||0===t.indexOf(n+"-")}while((e=e.parentNode)&&1===e.nodeType);return!1}}),target:function(e){var t=n.location&&n.location.hash;return t&&t.slice(1)===e.id},root:function(e){return e===a},focus:function(e){return e===C.activeElement&&(!C.hasFocus||C.hasFocus())&&!!(e.type||e.href||~e.tabIndex)},enabled:ge(!1),disabled:ge(!0),checked:function(e){var t=e.nodeName.toLowerCase();return"input"===t&&!!e.checked||"option"===t&&!!e.selected},selected:function(e){return e.parentNode&&e.parentNode.selectedIndex,!0===e.selected},empty:function(e){for(e=e.firstChild;e;e=e.nextSibling)if(e.nodeType<6)return!1;return!0},parent:function(e){return!b.pseudos.empty(e)},header:function(e){return J.test(e.nodeName)},input:function(e){return Q.test(e.nodeName)},button:function(e){var t=e.nodeName.toLowerCase();return"input"===t&&"button"===e.type||"button"===t},text:function(e){var t;return"input"===e.nodeName.toLowerCase()&&"text"===e.type&&(null==(t=e.getAttribute("type"))||"text"===t.toLowerCase())},first:ye(function(){return[0]}),last:ye(function(e,t){return[t-1]}),eq:ye(function(e,t,n){return[n<0?n+t:n]}),even:ye(function(e,t){for(var n=0;n<t;n+=2)e.push(n);return e}),odd:ye(function(e,t){for(var n=1;n<t;n+=2)e.push(n);return e}),lt:ye(function(e,t,n){for(var r=n<0?n+t:t<n?t:n;0<=--r;)e.push(r);return e}),gt:ye(function(e,t,n){for(var r=n<0?n+t:n;++r<t;)e.push(r);return e})}}).pseudos.nth=b.pseudos.eq,{radio:!0,checkbox:!0,file:!0,password:!0,image:!0})b.pseudos[e]=de(e);for(e in{submit:!0,reset:!0})b.pseudos[e]=he(e);function me(){}function xe(e){for(var t=0,n=e.length,r="";t<n;t++)r+=e[t].value;return r}function be(s,e,t){var u=e.dir,l=e.next,c=l||u,f=t&&"parentNode"===c,p=r++;return e.first?function(e,t,n){while(e=e[u])if(1===e.nodeType||f)return s(e,t,n);return!1}:function(e,t,n){var r,i,o,a=[k,p];if(n){while(e=e[u])if((1===e.nodeType||f)&&s(e,t,n))return!0}else while(e=e[u])if(1===e.nodeType||f)if(i=(o=e[S]||(e[S]={}))[e.uniqueID]||(o[e.uniqueID]={}),l&&l===e.nodeName.toLowerCase())e=e[u]||e;else{if((r=i[c])&&r[0]===k&&r[1]===p)return a[2]=r[2];if((i[c]=a)[2]=s(e,t,n))return!0}return!1}}function we(i){return 1<i.length?function(e,t,n){var r=i.length;while(r--)if(!i[r](e,t,n))return!1;return!0}:i[0]}function Te(e,t,n,r,i){for(var o,a=[],s=0,u=e.length,l=null!=t;s<u;s++)(o=e[s])&&(n&&!n(o,r,i)||(a.push(o),l&&t.push(s)));return a}function Ce(d,h,g,y,v,e){return y&&!y[S]&&(y=Ce(y)),v&&!v[S]&&(v=Ce(v,e)),le(function(e,t,n,r){var i,o,a,s=[],u=[],l=t.length,c=e||function(e,t,n){for(var r=0,i=t.length;r<i;r++)se(e,t[r],n);return n}(h||"*",n.nodeType?[n]:n,[]),f=!d||!e&&h?c:Te(c,s,d,n,r),p=g?v||(e?d:l||y)?[]:t:f;if(g&&g(f,p,n,r),y){i=Te(p,u),y(i,[],n,r),o=i.length;while(o--)(a=i[o])&&(p[u[o]]=!(f[u[o]]=a))}if(e){if(v||d){if(v){i=[],o=p.length;while(o--)(a=p[o])&&i.push(f[o]=a);v(null,p=[],i,r)}o=p.length;while(o--)(a=p[o])&&-1<(i=v?P(e,a):s[o])&&(e[i]=!(t[i]=a))}}else p=Te(p===t?p.splice(l,p.length):p),v?v(null,t,p,r):H.apply(t,p)})}function Ee(e){for(var i,t,n,r=e.length,o=b.relative[e[0].type],a=o||b.relative[" "],s=o?1:0,u=be(function(e){return e===i},a,!0),l=be(function(e){return-1<P(i,e)},a,!0),c=[function(e,t,n){var r=!o&&(n||t!==w)||((i=t).nodeType?u(e,t,n):l(e,t,n));return i=null,r}];s<r;s++)if(t=b.relative[e[s].type])c=[be(we(c),t)];else{if((t=b.filter[e[s].type].apply(null,e[s].matches))[S]){for(n=++s;n<r;n++)if(b.relative[e[n].type])break;return Ce(1<s&&we(c),1<s&&xe(e.slice(0,s-1).concat({value:" "===e[s-2].type?"*":""})).replace(B,"$1"),t,s<n&&Ee(e.slice(s,n)),n<r&&Ee(e=e.slice(n)),n<r&&xe(e))}c.push(t)}return we(c)}return me.prototype=b.filters=b.pseudos,b.setFilters=new me,h=se.tokenize=function(e,t){var n,r,i,o,a,s,u,l=x[e+" "];if(l)return t?0:l.slice(0);a=e,s=[],u=b.preFilter;while(a){for(o in n&&!(r=_.exec(a))||(r&&(a=a.slice(r[0].length)||a),s.push(i=[])),n=!1,(r=z.exec(a))&&(n=r.shift(),i.push({value:n,type:r[0].replace(B," ")}),a=a.slice(n.length)),b.filter)!(r=G[o].exec(a))||u[o]&&!(r=u[o](r))||(n=r.shift(),i.push({value:n,type:o,matches:r}),a=a.slice(n.length));if(!n)break}return t?a.length:a?se.error(e):x(e,s).slice(0)},f=se.compile=function(e,t){var n,y,v,m,x,r,i=[],o=[],a=A[e+" "];if(!a){t||(t=h(e)),n=t.length;while(n--)(a=Ee(t[n]))[S]?i.push(a):o.push(a);(a=A(e,(y=o,m=0<(v=i).length,x=0<y.length,r=function(e,t,n,r,i){var o,a,s,u=0,l="0",c=e&&[],f=[],p=w,d=e||x&&b.find.TAG("*",i),h=k+=null==p?1:Math.random()||.1,g=d.length;for(i&&(w=t==C||t||i);l!==g&&null!=(o=d[l]);l++){if(x&&o){a=0,t||o.ownerDocument==C||(T(o),n=!E);while(s=y[a++])if(s(o,t||C,n)){r.push(o);break}i&&(k=h)}m&&((o=!s&&o)&&u--,e&&c.push(o))}if(u+=l,m&&l!==u){a=0;while(s=v[a++])s(c,f,t,n);if(e){if(0<u)while(l--)c[l]||f[l]||(f[l]=q.call(r));f=Te(f)}H.apply(r,f),i&&!e&&0<f.length&&1<u+v.length&&se.uniqueSort(r)}return i&&(k=h,w=p),c},m?le(r):r))).selector=e}return a},g=se.select=function(e,t,n,r){var i,o,a,s,u,l="function"==typeof e&&e,c=!r&&h(e=l.selector||e);if(n=n||[],1===c.length){if(2<(o=c[0]=c[0].slice(0)).length&&"ID"===(a=o[0]).type&&9===t.nodeType&&E&&b.relative[o[1].type]){if(!(t=(b.find.ID(a.matches[0].replace(te,ne),t)||[])[0]))return n;l&&(t=t.parentNode),e=e.slice(o.shift().value.length)}i=G.needsContext.test(e)?0:o.length;while(i--){if(a=o[i],b.relative[s=a.type])break;if((u=b.find[s])&&(r=u(a.matches[0].replace(te,ne),ee.test(o[0].type)&&ve(t.parentNode)||t))){if(o.splice(i,1),!(e=r.length&&xe(o)))return H.apply(n,r),n;break}}}return(l||f(e,c))(r,t,!E,n,!t||ee.test(e)&&ve(t.parentNode)||t),n},d.sortStable=S.split("").sort(j).join("")===S,d.detectDuplicates=!!l,T(),d.sortDetached=ce(function(e){return 1&e.compareDocumentPosition(C.createElement("fieldset"))}),ce(function(e){return e.innerHTML="<a href='#'></a>","#"===e.firstChild.getAttribute("href")})||fe("type|href|height|width",function(e,t,n){if(!n)return e.getAttribute(t,"type"===t.toLowerCase()?1:2)}),d.attributes&&ce(function(e){return e.innerHTML="<input/>",e.firstChild.setAttribute("value",""),""===e.firstChild.getAttribute("value")})||fe("value",function(e,t,n){if(!n&&"input"===e.nodeName.toLowerCase())return e.defaultValue}),ce(function(e){return null==e.getAttribute("disabled")})||fe(R,function(e,t,n){var r;if(!n)return!0===e[t]?t.toLowerCase():(r=e.getAttributeNode(t))&&r.specified?r.value:null}),se}(C);S.find=d,S.expr=d.selectors,S.expr[":"]=S.expr.pseudos,S.uniqueSort=S.unique=d.uniqueSort,S.text=d.getText,S.isXMLDoc=d.isXML,S.contains=d.contains,S.escapeSelector=d.escape;var h=function(e,t,n){var r=[],i=void 0!==n;while((e=e[t])&&9!==e.nodeType)if(1===e.nodeType){if(i&&S(e).is(n))break;r.push(e)}return r},T=function(e,t){for(var n=[];e;e=e.nextSibling)1===e.nodeType&&e!==t&&n.push(e);return n},k=S.expr.match.needsContext;function A(e,t){return e.nodeName&&e.nodeName.toLowerCase()===t.toLowerCase()}var N=/^<([a-z][^\/\0>:\x20\t\r\n\f]*)[\x20\t\r\n\f]*\/?>(?:<\/\1>|)$/i;function j(e,n,r){return m(n)?S.grep(e,function(e,t){return!!n.call(e,t,e)!==r}):n.nodeType?S.grep(e,function(e){return e===n!==r}):"string"!=typeof n?S.grep(e,function(e){return-1<i.call(n,e)!==r}):S.filter(n,e,r)}S.filter=function(e,t,n){var r=t[0];return n&&(e=":not("+e+")"),1===t.length&&1===r.nodeType?S.find.matchesSelector(r,e)?[r]:[]:S.find.matches(e,S.grep(t,function(e){return 1===e.nodeType}))},S.fn.extend({find:function(e){var t,n,r=this.length,i=this;if("string"!=typeof e)return this.pushStack(S(e).filter(function(){for(t=0;t<r;t++)if(S.contains(i[t],this))return!0}));for(n=this.pushStack([]),t=0;t<r;t++)S.find(e,i[t],n);return 1<r?S.uniqueSort(n):n},filter:function(e){return this.pushStack(j(this,e||[],!1))},not:function(e){return this.pushStack(j(this,e||[],!0))},is:function(e){return!!j(this,"string"==typeof e&&k.test(e)?S(e):e||[],!1).length}});var D,q=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]+))$/;(S.fn.init=function(e,t,n){var r,i;if(!e)return this;if(n=n||D,"string"==typeof e){if(!(r="<"===e[0]&&">"===e[e.length-1]&&3<=e.length?[null,e,null]:q.exec(e))||!r[1]&&t)return!t||t.jquery?(t||n).find(e):this.constructor(t).find(e);if(r[1]){if(t=t instanceof S?t[0]:t,S.merge(this,S.parseHTML(r[1],t&&t.nodeType?t.ownerDocument||t:E,!0)),N.test(r[1])&&S.isPlainObject(t))for(r in t)m(this[r])?this[r](t[r]):this.attr(r,t[r]);return this}return(i=E.getElementById(r[2]))&&(this[0]=i,this.length=1),this}return e.nodeType?(this[0]=e,this.length=1,this):m(e)?void 0!==n.ready?n.ready(e):e(S):S.makeArray(e,this)}).prototype=S.fn,D=S(E);var L=/^(?:parents|prev(?:Until|All))/,H={children:!0,contents:!0,next:!0,prev:!0};function O(e,t){while((e=e[t])&&1!==e.nodeType);return e}S.fn.extend({has:function(e){var t=S(e,this),n=t.length;return this.filter(function(){for(var e=0;e<n;e++)if(S.contains(this,t[e]))return!0})},closest:function(e,t){var n,r=0,i=this.length,o=[],a="string"!=typeof e&&S(e);if(!k.test(e))for(;r<i;r++)for(n=this[r];n&&n!==t;n=n.parentNode)if(n.nodeType<11&&(a?-1<a.index(n):1===n.nodeType&&S.find.matchesSelector(n,e))){o.push(n);break}return this.pushStack(1<o.length?S.uniqueSort(o):o)},index:function(e){return e?"string"==typeof e?i.call(S(e),this[0]):i.call(this,e.jquery?e[0]:e):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(e,t){return this.pushStack(S.uniqueSort(S.merge(this.get(),S(e,t))))},addBack:function(e){return this.add(null==e?this.prevObject:this.prevObject.filter(e))}}),S.each({parent:function(e){var t=e.parentNode;return t&&11!==t.nodeType?t:null},parents:function(e){return h(e,"parentNode")},parentsUntil:function(e,t,n){return h(e,"parentNode",n)},next:function(e){return O(e,"nextSibling")},prev:function(e){return O(e,"previousSibling")},nextAll:function(e){return h(e,"nextSibling")},prevAll:function(e){return h(e,"previousSibling")},nextUntil:function(e,t,n){return h(e,"nextSibling",n)},prevUntil:function(e,t,n){return h(e,"previousSibling",n)},siblings:function(e){return T((e.parentNode||{}).firstChild,e)},children:function(e){return T(e.firstChild)},contents:function(e){return null!=e.contentDocument&&r(e.contentDocument)?e.contentDocument:(A(e,"template")&&(e=e.content||e),S.merge([],e.childNodes))}},function(r,i){S.fn[r]=function(e,t){var n=S.map(this,i,e);return"Until"!==r.slice(-5)&&(t=e),t&&"string"==typeof t&&(n=S.filter(t,n)),1<this.length&&(H[r]||S.uniqueSort(n),L.test(r)&&n.reverse()),this.pushStack(n)}});var P=/[^\x20\t\r\n\f]+/g;function R(e){return e}function M(e){throw e}function I(e,t,n,r){var i;try{e&&m(i=e.promise)?i.call(e).done(t).fail(n):e&&m(i=e.then)?i.call(e,t,n):t.apply(void 0,[e].slice(r))}catch(e){n.apply(void 0,[e])}}S.Callbacks=function(r){var e,n;r="string"==typeof r?(e=r,n={},S.each(e.match(P)||[],function(e,t){n[t]=!0}),n):S.extend({},r);var i,t,o,a,s=[],u=[],l=-1,c=function(){for(a=a||r.once,o=i=!0;u.length;l=-1){t=u.shift();while(++l<s.length)!1===s[l].apply(t[0],t[1])&&r.stopOnFalse&&(l=s.length,t=!1)}r.memory||(t=!1),i=!1,a&&(s=t?[]:"")},f={add:function(){return s&&(t&&!i&&(l=s.length-1,u.push(t)),function n(e){S.each(e,function(e,t){m(t)?r.unique&&f.has(t)||s.push(t):t&&t.length&&"string"!==w(t)&&n(t)})}(arguments),t&&!i&&c()),this},remove:function(){return S.each(arguments,function(e,t){var n;while(-1<(n=S.inArray(t,s,n)))s.splice(n,1),n<=l&&l--}),this},has:function(e){return e?-1<S.inArray(e,s):0<s.length},empty:function(){return s&&(s=[]),this},disable:function(){return a=u=[],s=t="",this},disabled:function(){return!s},lock:function(){return a=u=[],t||i||(s=t=""),this},locked:function(){return!!a},fireWith:function(e,t){return a||(t=[e,(t=t||[]).slice?t.slice():t],u.push(t),i||c()),this},fire:function(){return f.fireWith(this,arguments),this},fired:function(){return!!o}};return f},S.extend({Deferred:function(e){var o=[["notify","progress",S.Callbacks("memory"),S.Callbacks("memory"),2],["resolve","done",S.Callbacks("once memory"),S.Callbacks("once memory"),0,"resolved"],["reject","fail",S.Callbacks("once memory"),S.Callbacks("once memory"),1,"rejected"]],i="pending",a={state:function(){return i},always:function(){return s.done(arguments).fail(arguments),this},"catch":function(e){return a.then(null,e)},pipe:function(){var i=arguments;return S.Deferred(function(r){S.each(o,function(e,t){var n=m(i[t[4]])&&i[t[4]];s[t[1]](function(){var e=n&&n.apply(this,arguments);e&&m(e.promise)?e.promise().progress(r.notify).done(r.resolve).fail(r.reject):r[t[0]+"With"](this,n?[e]:arguments)})}),i=null}).promise()},then:function(t,n,r){var u=0;function l(i,o,a,s){return function(){var n=this,r=arguments,e=function(){var e,t;if(!(i<u)){if((e=a.apply(n,r))===o.promise())throw new TypeError("Thenable self-resolution");t=e&&("object"==typeof e||"function"==typeof e)&&e.then,m(t)?s?t.call(e,l(u,o,R,s),l(u,o,M,s)):(u++,t.call(e,l(u,o,R,s),l(u,o,M,s),l(u,o,R,o.notifyWith))):(a!==R&&(n=void 0,r=[e]),(s||o.resolveWith)(n,r))}},t=s?e:function(){try{e()}catch(e){S.Deferred.exceptionHook&&S.Deferred.exceptionHook(e,t.stackTrace),u<=i+1&&(a!==M&&(n=void 0,r=[e]),o.rejectWith(n,r))}};i?t():(S.Deferred.getStackHook&&(t.stackTrace=S.Deferred.getStackHook()),C.setTimeout(t))}}return S.Deferred(function(e){o[0][3].add(l(0,e,m(r)?r:R,e.notifyWith)),o[1][3].add(l(0,e,m(t)?t:R)),o[2][3].add(l(0,e,m(n)?n:M))}).promise()},promise:function(e){return null!=e?S.extend(e,a):a}},s={};return S.each(o,function(e,t){var n=t[2],r=t[5];a[t[1]]=n.add,r&&n.add(function(){i=r},o[3-e][2].disable,o[3-e][3].disable,o[0][2].lock,o[0][3].lock),n.add(t[3].fire),s[t[0]]=function(){return s[t[0]+"With"](this===s?void 0:this,arguments),this},s[t[0]+"With"]=n.fireWith}),a.promise(s),e&&e.call(s,s),s},when:function(e){var n=arguments.length,t=n,r=Array(t),i=s.call(arguments),o=S.Deferred(),a=function(t){return function(e){r[t]=this,i[t]=1<arguments.length?s.call(arguments):e,--n||o.resolveWith(r,i)}};if(n<=1&&(I(e,o.done(a(t)).resolve,o.reject,!n),"pending"===o.state()||m(i[t]&&i[t].then)))return o.then();while(t--)I(i[t],a(t),o.reject);return o.promise()}});var W=/^(Eval|Internal|Range|Reference|Syntax|Type|URI)Error$/;S.Deferred.exceptionHook=function(e,t){C.console&&C.console.warn&&e&&W.test(e.name)&&C.console.warn("jQuery.Deferred exception: "+e.message,e.stack,t)},S.readyException=function(e){C.setTimeout(function(){throw e})};var F=S.Deferred();function $(){E.removeEventListener("DOMContentLoaded",$),C.removeEventListener("load",$),S.ready()}S.fn.ready=function(e){return F.then(e)["catch"](function(e){S.readyException(e)}),this},S.extend({isReady:!1,readyWait:1,ready:function(e){(!0===e?--S.readyWait:S.isReady)||(S.isReady=!0)!==e&&0<--S.readyWait||F.resolveWith(E,[S])}}),S.ready.then=F.then,"complete"===E.readyState||"loading"!==E.readyState&&!E.documentElement.doScroll?C.setTimeout(S.ready):(E.addEventListener("DOMContentLoaded",$),C.addEventListener("load",$));var B=function(e,t,n,r,i,o,a){var s=0,u=e.length,l=null==n;if("object"===w(n))for(s in i=!0,n)B(e,t,s,n[s],!0,o,a);else if(void 0!==r&&(i=!0,m(r)||(a=!0),l&&(a?(t.call(e,r),t=null):(l=t,t=function(e,t,n){return l.call(S(e),n)})),t))for(;s<u;s++)t(e[s],n,a?r:r.call(e[s],s,t(e[s],n)));return i?e:l?t.call(e):u?t(e[0],n):o},_=/^-ms-/,z=/-([a-z])/g;function U(e,t){return t.toUpperCase()}function X(e){return e.replace(_,"ms-").replace(z,U)}var V=function(e){return 1===e.nodeType||9===e.nodeType||!+e.nodeType};function G(){this.expando=S.expando+G.uid++}G.uid=1,G.prototype={cache:function(e){var t=e[this.expando];return t||(t={},V(e)&&(e.nodeType?e[this.expando]=t:Object.defineProperty(e,this.expando,{value:t,configurable:!0}))),t},set:function(e,t,n){var r,i=this.cache(e);if("string"==typeof t)i[X(t)]=n;else for(r in t)i[X(r)]=t[r];return i},get:function(e,t){return void 0===t?this.cache(e):e[this.expando]&&e[this.expando][X(t)]},access:function(e,t,n){return void 0===t||t&&"string"==typeof t&&void 0===n?this.get(e,t):(this.set(e,t,n),void 0!==n?n:t)},remove:function(e,t){var n,r=e[this.expando];if(void 0!==r){if(void 0!==t){n=(t=Array.isArray(t)?t.map(X):(t=X(t))in r?[t]:t.match(P)||[]).length;while(n--)delete r[t[n]]}(void 0===t||S.isEmptyObject(r))&&(e.nodeType?e[this.expando]=void 0:delete e[this.expando])}},hasData:function(e){var t=e[this.expando];return void 0!==t&&!S.isEmptyObject(t)}};var Y=new G,Q=new G,J=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,K=/[A-Z]/g;function Z(e,t,n){var r,i;if(void 0===n&&1===e.nodeType)if(r="data-"+t.replace(K,"-$&").toLowerCase(),"string"==typeof(n=e.getAttribute(r))){try{n="true"===(i=n)||"false"!==i&&("null"===i?null:i===+i+""?+i:J.test(i)?JSON.parse(i):i)}catch(e){}Q.set(e,t,n)}else n=void 0;return n}S.extend({hasData:function(e){return Q.hasData(e)||Y.hasData(e)},data:function(e,t,n){return Q.access(e,t,n)},removeData:function(e,t){Q.remove(e,t)},_data:function(e,t,n){return Y.access(e,t,n)},_removeData:function(e,t){Y.remove(e,t)}}),S.fn.extend({data:function(n,e){var t,r,i,o=this[0],a=o&&o.attributes;if(void 0===n){if(this.length&&(i=Q.get(o),1===o.nodeType&&!Y.get(o,"hasDataAttrs"))){t=a.length;while(t--)a[t]&&0===(r=a[t].name).indexOf("data-")&&(r=X(r.slice(5)),Z(o,r,i[r]));Y.set(o,"hasDataAttrs",!0)}return i}return"object"==typeof n?this.each(function(){Q.set(this,n)}):B(this,function(e){var t;if(o&&void 0===e)return void 0!==(t=Q.get(o,n))?t:void 0!==(t=Z(o,n))?t:void 0;this.each(function(){Q.set(this,n,e)})},null,e,1<arguments.length,null,!0)},removeData:function(e){return this.each(function(){Q.remove(this,e)})}}),S.extend({queue:function(e,t,n){var r;if(e)return t=(t||"fx")+"queue",r=Y.get(e,t),n&&(!r||Array.isArray(n)?r=Y.access(e,t,S.makeArray(n)):r.push(n)),r||[]},dequeue:function(e,t){t=t||"fx";var n=S.queue(e,t),r=n.length,i=n.shift(),o=S._queueHooks(e,t);"inprogress"===i&&(i=n.shift(),r--),i&&("fx"===t&&n.unshift("inprogress"),delete o.stop,i.call(e,function(){S.dequeue(e,t)},o)),!r&&o&&o.empty.fire()},_queueHooks:function(e,t){var n=t+"queueHooks";return Y.get(e,n)||Y.access(e,n,{empty:S.Callbacks("once memory").add(function(){Y.remove(e,[t+"queue",n])})})}}),S.fn.extend({queue:function(t,n){var e=2;return"string"!=typeof t&&(n=t,t="fx",e--),arguments.length<e?S.queue(this[0],t):void 0===n?this:this.each(function(){var e=S.queue(this,t,n);S._queueHooks(this,t),"fx"===t&&"inprogress"!==e[0]&&S.dequeue(this,t)})},dequeue:function(e){return this.each(function(){S.dequeue(this,e)})},clearQueue:function(e){return this.queue(e||"fx",[])},promise:function(e,t){var n,r=1,i=S.Deferred(),o=this,a=this.length,s=function(){--r||i.resolveWith(o,[o])};"string"!=typeof e&&(t=e,e=void 0),e=e||"fx";while(a--)(n=Y.get(o[a],e+"queueHooks"))&&n.empty&&(r++,n.empty.add(s));return s(),i.promise(t)}});var ee=/[+-]?(?:\d*\.|)\d+(?:[eE][+-]?\d+|)/.source,te=new RegExp("^(?:([+-])=|)("+ee+")([a-z%]*)$","i"),ne=["Top","Right","Bottom","Left"],re=E.documentElement,ie=function(e){return S.contains(e.ownerDocument,e)},oe={composed:!0};re.getRootNode&&(ie=function(e){return S.contains(e.ownerDocument,e)||e.getRootNode(oe)===e.ownerDocument});var ae=function(e,t){return"none"===(e=t||e).style.display||""===e.style.display&&ie(e)&&"none"===S.css(e,"display")};function se(e,t,n,r){var i,o,a=20,s=r?function(){return r.cur()}:function(){return S.css(e,t,"")},u=s(),l=n&&n[3]||(S.cssNumber[t]?"":"px"),c=e.nodeType&&(S.cssNumber[t]||"px"!==l&&+u)&&te.exec(S.css(e,t));if(c&&c[3]!==l){u/=2,l=l||c[3],c=+u||1;while(a--)S.style(e,t,c+l),(1-o)*(1-(o=s()/u||.5))<=0&&(a=0),c/=o;c*=2,S.style(e,t,c+l),n=n||[]}return n&&(c=+c||+u||0,i=n[1]?c+(n[1]+1)*n[2]:+n[2],r&&(r.unit=l,r.start=c,r.end=i)),i}var ue={};function le(e,t){for(var n,r,i,o,a,s,u,l=[],c=0,f=e.length;c<f;c++)(r=e[c]).style&&(n=r.style.display,t?("none"===n&&(l[c]=Y.get(r,"display")||null,l[c]||(r.style.display="")),""===r.style.display&&ae(r)&&(l[c]=(u=a=o=void 0,a=(i=r).ownerDocument,s=i.nodeName,(u=ue[s])||(o=a.body.appendChild(a.createElement(s)),u=S.css(o,"display"),o.parentNode.removeChild(o),"none"===u&&(u="block"),ue[s]=u)))):"none"!==n&&(l[c]="none",Y.set(r,"display",n)));for(c=0;c<f;c++)null!=l[c]&&(e[c].style.display=l[c]);return e}S.fn.extend({show:function(){return le(this,!0)},hide:function(){return le(this)},toggle:function(e){return"boolean"==typeof e?e?this.show():this.hide():this.each(function(){ae(this)?S(this).show():S(this).hide()})}});var ce,fe,pe=/^(?:checkbox|radio)$/i,de=/<([a-z][^\/\0>\x20\t\r\n\f]*)/i,he=/^$|^module$|\/(?:java|ecma)script/i;ce=E.createDocumentFragment().appendChild(E.createElement("div")),(fe=E.createElement("input")).setAttribute("type","radio"),fe.setAttribute("checked","checked"),fe.setAttribute("name","t"),ce.appendChild(fe),v.checkClone=ce.cloneNode(!0).cloneNode(!0).lastChild.checked,ce.innerHTML="<textarea>x</textarea>",v.noCloneChecked=!!ce.cloneNode(!0).lastChild.defaultValue,ce.innerHTML="<option></option>",v.option=!!ce.lastChild;var ge={thead:[1,"<table>","</table>"],col:[2,"<table><colgroup>","</colgroup></table>"],tr:[2,"<table><tbody>","</tbody></table>"],td:[3,"<table><tbody><tr>","</tr></tbody></table>"],_default:[0,"",""]};function ye(e,t){var n;return n="undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t||"*"):"undefined"!=typeof e.querySelectorAll?e.querySelectorAll(t||"*"):[],void 0===t||t&&A(e,t)?S.merge([e],n):n}function ve(e,t){for(var n=0,r=e.length;n<r;n++)Y.set(e[n],"globalEval",!t||Y.get(t[n],"globalEval"))}ge.tbody=ge.tfoot=ge.colgroup=ge.caption=ge.thead,ge.th=ge.td,v.option||(ge.optgroup=ge.option=[1,"<select multiple='multiple'>","</select>"]);var me=/<|&#?\w+;/;function xe(e,t,n,r,i){for(var o,a,s,u,l,c,f=t.createDocumentFragment(),p=[],d=0,h=e.length;d<h;d++)if((o=e[d])||0===o)if("object"===w(o))S.merge(p,o.nodeType?[o]:o);else if(me.test(o)){a=a||f.appendChild(t.createElement("div")),s=(de.exec(o)||["",""])[1].toLowerCase(),u=ge[s]||ge._default,a.innerHTML=u[1]+S.htmlPrefilter(o)+u[2],c=u[0];while(c--)a=a.lastChild;S.merge(p,a.childNodes),(a=f.firstChild).textContent=""}else p.push(t.createTextNode(o));f.textContent="",d=0;while(o=p[d++])if(r&&-1<S.inArray(o,r))i&&i.push(o);else if(l=ie(o),a=ye(f.appendChild(o),"script"),l&&ve(a),n){c=0;while(o=a[c++])he.test(o.type||"")&&n.push(o)}return f}var be=/^([^.]*)(?:\.(.+)|)/;function we(){return!0}function Te(){return!1}function Ce(e,t){return e===function(){try{return E.activeElement}catch(e){}}()==("focus"===t)}function Ee(e,t,n,r,i,o){var a,s;if("object"==typeof t){for(s in"string"!=typeof n&&(r=r||n,n=void 0),t)Ee(e,s,n,r,t[s],o);return e}if(null==r&&null==i?(i=n,r=n=void 0):null==i&&("string"==typeof n?(i=r,r=void 0):(i=r,r=n,n=void 0)),!1===i)i=Te;else if(!i)return e;return 1===o&&(a=i,(i=function(e){return S().off(e),a.apply(this,arguments)}).guid=a.guid||(a.guid=S.guid++)),e.each(function(){S.event.add(this,t,i,r,n)})}function Se(e,i,o){o?(Y.set(e,i,!1),S.event.add(e,i,{namespace:!1,handler:function(e){var t,n,r=Y.get(this,i);if(1&e.isTrigger&&this[i]){if(r.length)(S.event.special[i]||{}).delegateType&&e.stopPropagation();else if(r=s.call(arguments),Y.set(this,i,r),t=o(this,i),this[i](),r!==(n=Y.get(this,i))||t?Y.set(this,i,!1):n={},r!==n)return e.stopImmediatePropagation(),e.preventDefault(),n&&n.value}else r.length&&(Y.set(this,i,{value:S.event.trigger(S.extend(r[0],S.Event.prototype),r.slice(1),this)}),e.stopImmediatePropagation())}})):void 0===Y.get(e,i)&&S.event.add(e,i,we)}S.event={global:{},add:function(t,e,n,r,i){var o,a,s,u,l,c,f,p,d,h,g,y=Y.get(t);if(V(t)){n.handler&&(n=(o=n).handler,i=o.selector),i&&S.find.matchesSelector(re,i),n.guid||(n.guid=S.guid++),(u=y.events)||(u=y.events=Object.create(null)),(a=y.handle)||(a=y.handle=function(e){return"undefined"!=typeof S&&S.event.triggered!==e.type?S.event.dispatch.apply(t,arguments):void 0}),l=(e=(e||"").match(P)||[""]).length;while(l--)d=g=(s=be.exec(e[l])||[])[1],h=(s[2]||"").split(".").sort(),d&&(f=S.event.special[d]||{},d=(i?f.delegateType:f.bindType)||d,f=S.event.special[d]||{},c=S.extend({type:d,origType:g,data:r,handler:n,guid:n.guid,selector:i,needsContext:i&&S.expr.match.needsContext.test(i),namespace:h.join(".")},o),(p=u[d])||((p=u[d]=[]).delegateCount=0,f.setup&&!1!==f.setup.call(t,r,h,a)||t.addEventListener&&t.addEventListener(d,a)),f.add&&(f.add.call(t,c),c.handler.guid||(c.handler.guid=n.guid)),i?p.splice(p.delegateCount++,0,c):p.push(c),S.event.global[d]=!0)}},remove:function(e,t,n,r,i){var o,a,s,u,l,c,f,p,d,h,g,y=Y.hasData(e)&&Y.get(e);if(y&&(u=y.events)){l=(t=(t||"").match(P)||[""]).length;while(l--)if(d=g=(s=be.exec(t[l])||[])[1],h=(s[2]||"").split(".").sort(),d){f=S.event.special[d]||{},p=u[d=(r?f.delegateType:f.bindType)||d]||[],s=s[2]&&new RegExp("(^|\\.)"+h.join("\\.(?:.*\\.|)")+"(\\.|$)"),a=o=p.length;while(o--)c=p[o],!i&&g!==c.origType||n&&n.guid!==c.guid||s&&!s.test(c.namespace)||r&&r!==c.selector&&("**"!==r||!c.selector)||(p.splice(o,1),c.selector&&p.delegateCount--,f.remove&&f.remove.call(e,c));a&&!p.length&&(f.teardown&&!1!==f.teardown.call(e,h,y.handle)||S.removeEvent(e,d,y.handle),delete u[d])}else for(d in u)S.event.remove(e,d+t[l],n,r,!0);S.isEmptyObject(u)&&Y.remove(e,"handle events")}},dispatch:function(e){var t,n,r,i,o,a,s=new Array(arguments.length),u=S.event.fix(e),l=(Y.get(this,"events")||Object.create(null))[u.type]||[],c=S.event.special[u.type]||{};for(s[0]=u,t=1;t<arguments.length;t++)s[t]=arguments[t];if(u.delegateTarget=this,!c.preDispatch||!1!==c.preDispatch.call(this,u)){a=S.event.handlers.call(this,u,l),t=0;while((i=a[t++])&&!u.isPropagationStopped()){u.currentTarget=i.elem,n=0;while((o=i.handlers[n++])&&!u.isImmediatePropagationStopped())u.rnamespace&&!1!==o.namespace&&!u.rnamespace.test(o.namespace)||(u.handleObj=o,u.data=o.data,void 0!==(r=((S.event.special[o.origType]||{}).handle||o.handler).apply(i.elem,s))&&!1===(u.result=r)&&(u.preventDefault(),u.stopPropagation()))}return c.postDispatch&&c.postDispatch.call(this,u),u.result}},handlers:function(e,t){var n,r,i,o,a,s=[],u=t.delegateCount,l=e.target;if(u&&l.nodeType&&!("click"===e.type&&1<=e.button))for(;l!==this;l=l.parentNode||this)if(1===l.nodeType&&("click"!==e.type||!0!==l.disabled)){for(o=[],a={},n=0;n<u;n++)void 0===a[i=(r=t[n]).selector+" "]&&(a[i]=r.needsContext?-1<S(i,this).index(l):S.find(i,this,null,[l]).length),a[i]&&o.push(r);o.length&&s.push({elem:l,handlers:o})}return l=this,u<t.length&&s.push({elem:l,handlers:t.slice(u)}),s},addProp:function(t,e){Object.defineProperty(S.Event.prototype,t,{enumerable:!0,configurable:!0,get:m(e)?function(){if(this.originalEvent)return e(this.originalEvent)}:function(){if(this.originalEvent)return this.originalEvent[t]},set:function(e){Object.defineProperty(this,t,{enumerable:!0,configurable:!0,writable:!0,value:e})}})},fix:function(e){return e[S.expando]?e:new S.Event(e)},special:{load:{noBubble:!0},click:{setup:function(e){var t=this||e;return pe.test(t.type)&&t.click&&A(t,"input")&&Se(t,"click",we),!1},trigger:function(e){var t=this||e;return pe.test(t.type)&&t.click&&A(t,"input")&&Se(t,"click"),!0},_default:function(e){var t=e.target;return pe.test(t.type)&&t.click&&A(t,"input")&&Y.get(t,"click")||A(t,"a")}},beforeunload:{postDispatch:function(e){void 0!==e.result&&e.originalEvent&&(e.originalEvent.returnValue=e.result)}}}},S.removeEvent=function(e,t,n){e.removeEventListener&&e.removeEventListener(t,n)},S.Event=function(e,t){if(!(this instanceof S.Event))return new S.Event(e,t);e&&e.type?(this.originalEvent=e,this.type=e.type,this.isDefaultPrevented=e.defaultPrevented||void 0===e.defaultPrevented&&!1===e.returnValue?we:Te,this.target=e.target&&3===e.target.nodeType?e.target.parentNode:e.target,this.currentTarget=e.currentTarget,this.relatedTarget=e.relatedTarget):this.type=e,t&&S.extend(this,t),this.timeStamp=e&&e.timeStamp||Date.now(),this[S.expando]=!0},S.Event.prototype={constructor:S.Event,isDefaultPrevented:Te,isPropagationStopped:Te,isImmediatePropagationStopped:Te,isSimulated:!1,preventDefault:function(){var e=this.originalEvent;this.isDefaultPrevented=we,e&&!this.isSimulated&&e.preventDefault()},stopPropagation:function(){var e=this.originalEvent;this.isPropagationStopped=we,e&&!this.isSimulated&&e.stopPropagation()},stopImmediatePropagation:function(){var e=this.originalEvent;this.isImmediatePropagationStopped=we,e&&!this.isSimulated&&e.stopImmediatePropagation(),this.stopPropagation()}},S.each({altKey:!0,bubbles:!0,cancelable:!0,changedTouches:!0,ctrlKey:!0,detail:!0,eventPhase:!0,metaKey:!0,pageX:!0,pageY:!0,shiftKey:!0,view:!0,"char":!0,code:!0,charCode:!0,key:!0,keyCode:!0,button:!0,buttons:!0,clientX:!0,clientY:!0,offsetX:!0,offsetY:!0,pointerId:!0,pointerType:!0,screenX:!0,screenY:!0,targetTouches:!0,toElement:!0,touches:!0,which:!0},S.event.addProp),S.each({focus:"focusin",blur:"focusout"},function(t,e){S.event.special[t]={setup:function(){return Se(this,t,Ce),!1},trigger:function(){return Se(this,t),!0},_default:function(e){return Y.get(e.target,t)},delegateType:e}}),S.each({mouseenter:"mouseover",mouseleave:"mouseout",pointerenter:"pointerover",pointerleave:"pointerout"},function(e,i){S.event.special[e]={delegateType:i,bindType:i,handle:function(e){var t,n=e.relatedTarget,r=e.handleObj;return n&&(n===this||S.contains(this,n))||(e.type=r.origType,t=r.handler.apply(this,arguments),e.type=i),t}}}),S.fn.extend({on:function(e,t,n,r){return Ee(this,e,t,n,r)},one:function(e,t,n,r){return Ee(this,e,t,n,r,1)},off:function(e,t,n){var r,i;if(e&&e.preventDefault&&e.handleObj)return r=e.handleObj,S(e.delegateTarget).off(r.namespace?r.origType+"."+r.namespace:r.origType,r.selector,r.handler),this;if("object"==typeof e){for(i in e)this.off(i,t,e[i]);return this}return!1!==t&&"function"!=typeof t||(n=t,t=void 0),!1===n&&(n=Te),this.each(function(){S.event.remove(this,e,n,t)})}});var ke=/<script|<style|<link/i,Ae=/checked\s*(?:[^=]|=\s*.checked.)/i,Ne=/^\s*<!\[CDATA\[|\]\]>\s*$/g;function je(e,t){return A(e,"table")&&A(11!==t.nodeType?t:t.firstChild,"tr")&&S(e).children("tbody")[0]||e}function De(e){return e.type=(null!==e.getAttribute("type"))+"/"+e.type,e}function qe(e){return"true/"===(e.type||"").slice(0,5)?e.type=e.type.slice(5):e.removeAttribute("type"),e}function Le(e,t){var n,r,i,o,a,s;if(1===t.nodeType){if(Y.hasData(e)&&(s=Y.get(e).events))for(i in Y.remove(t,"handle events"),s)for(n=0,r=s[i].length;n<r;n++)S.event.add(t,i,s[i][n]);Q.hasData(e)&&(o=Q.access(e),a=S.extend({},o),Q.set(t,a))}}function He(n,r,i,o){r=g(r);var e,t,a,s,u,l,c=0,f=n.length,p=f-1,d=r[0],h=m(d);if(h||1<f&&"string"==typeof d&&!v.checkClone&&Ae.test(d))return n.each(function(e){var t=n.eq(e);h&&(r[0]=d.call(this,e,t.html())),He(t,r,i,o)});if(f&&(t=(e=xe(r,n[0].ownerDocument,!1,n,o)).firstChild,1===e.childNodes.length&&(e=t),t||o)){for(s=(a=S.map(ye(e,"script"),De)).length;c<f;c++)u=e,c!==p&&(u=S.clone(u,!0,!0),s&&S.merge(a,ye(u,"script"))),i.call(n[c],u,c);if(s)for(l=a[a.length-1].ownerDocument,S.map(a,qe),c=0;c<s;c++)u=a[c],he.test(u.type||"")&&!Y.access(u,"globalEval")&&S.contains(l,u)&&(u.src&&"module"!==(u.type||"").toLowerCase()?S._evalUrl&&!u.noModule&&S._evalUrl(u.src,{nonce:u.nonce||u.getAttribute("nonce")},l):b(u.textContent.replace(Ne,""),u,l))}return n}function Oe(e,t,n){for(var r,i=t?S.filter(t,e):e,o=0;null!=(r=i[o]);o++)n||1!==r.nodeType||S.cleanData(ye(r)),r.parentNode&&(n&&ie(r)&&ve(ye(r,"script")),r.parentNode.removeChild(r));return e}S.extend({htmlPrefilter:function(e){return e},clone:function(e,t,n){var r,i,o,a,s,u,l,c=e.cloneNode(!0),f=ie(e);if(!(v.noCloneChecked||1!==e.nodeType&&11!==e.nodeType||S.isXMLDoc(e)))for(a=ye(c),r=0,i=(o=ye(e)).length;r<i;r++)s=o[r],u=a[r],void 0,"input"===(l=u.nodeName.toLowerCase())&&pe.test(s.type)?u.checked=s.checked:"input"!==l&&"textarea"!==l||(u.defaultValue=s.defaultValue);if(t)if(n)for(o=o||ye(e),a=a||ye(c),r=0,i=o.length;r<i;r++)Le(o[r],a[r]);else Le(e,c);return 0<(a=ye(c,"script")).length&&ve(a,!f&&ye(e,"script")),c},cleanData:function(e){for(var t,n,r,i=S.event.special,o=0;void 0!==(n=e[o]);o++)if(V(n)){if(t=n[Y.expando]){if(t.events)for(r in t.events)i[r]?S.event.remove(n,r):S.removeEvent(n,r,t.handle);n[Y.expando]=void 0}n[Q.expando]&&(n[Q.expando]=void 0)}}}),S.fn.extend({detach:function(e){return Oe(this,e,!0)},remove:function(e){return Oe(this,e)},text:function(e){return B(this,function(e){return void 0===e?S.text(this):this.empty().each(function(){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||(this.textContent=e)})},null,e,arguments.length)},append:function(){return He(this,arguments,function(e){1!==this.nodeType&&11!==this.nodeType&&9!==this.nodeType||je(this,e).appendChild(e)})},prepend:function(){return He(this,arguments,function(e){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var t=je(this,e);t.insertBefore(e,t.firstChild)}})},before:function(){return He(this,arguments,function(e){this.parentNode&&this.parentNode.insertBefore(e,this)})},after:function(){return He(this,arguments,function(e){this.parentNode&&this.parentNode.insertBefore(e,this.nextSibling)})},empty:function(){for(var e,t=0;null!=(e=this[t]);t++)1===e.nodeType&&(S.cleanData(ye(e,!1)),e.textContent="");return this},clone:function(e,t){return e=null!=e&&e,t=null==t?e:t,this.map(function(){return S.clone(this,e,t)})},html:function(e){return B(this,function(e){var t=this[0]||{},n=0,r=this.length;if(void 0===e&&1===t.nodeType)return t.innerHTML;if("string"==typeof e&&!ke.test(e)&&!ge[(de.exec(e)||["",""])[1].toLowerCase()]){e=S.htmlPrefilter(e);try{for(;n<r;n++)1===(t=this[n]||{}).nodeType&&(S.cleanData(ye(t,!1)),t.innerHTML=e);t=0}catch(e){}}t&&this.empty().append(e)},null,e,arguments.length)},replaceWith:function(){var n=[];return He(this,arguments,function(e){var t=this.parentNode;S.inArray(this,n)<0&&(S.cleanData(ye(this)),t&&t.replaceChild(e,this))},n)}}),S.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(e,a){S.fn[e]=function(e){for(var t,n=[],r=S(e),i=r.length-1,o=0;o<=i;o++)t=o===i?this:this.clone(!0),S(r[o])[a](t),u.apply(n,t.get());return this.pushStack(n)}});var Pe=new RegExp("^("+ee+")(?!px)[a-z%]+$","i"),Re=/^--/,Me=function(e){var t=e.ownerDocument.defaultView;return t&&t.opener||(t=C),t.getComputedStyle(e)},Ie=function(e,t,n){var r,i,o={};for(i in t)o[i]=e.style[i],e.style[i]=t[i];for(i in r=n.call(e),t)e.style[i]=o[i];return r},We=new RegExp(ne.join("|"),"i"),Fe="[\\x20\\t\\r\\n\\f]",$e=new RegExp("^"+Fe+"+|((?:^|[^\\\\])(?:\\\\.)*)"+Fe+"+$","g");function Be(e,t,n){var r,i,o,a,s=Re.test(t),u=e.style;return(n=n||Me(e))&&(a=n.getPropertyValue(t)||n[t],s&&a&&(a=a.replace($e,"$1")||void 0),""!==a||ie(e)||(a=S.style(e,t)),!v.pixelBoxStyles()&&Pe.test(a)&&We.test(t)&&(r=u.width,i=u.minWidth,o=u.maxWidth,u.minWidth=u.maxWidth=u.width=a,a=n.width,u.width=r,u.minWidth=i,u.maxWidth=o)),void 0!==a?a+"":a}function _e(e,t){return{get:function(){if(!e())return(this.get=t).apply(this,arguments);delete this.get}}}!function(){function e(){if(l){u.style.cssText="position:absolute;left:-11111px;width:60px;margin-top:1px;padding:0;border:0",l.style.cssText="position:relative;display:block;box-sizing:border-box;overflow:scroll;margin:auto;border:1px;padding:1px;width:60%;top:1%",re.appendChild(u).appendChild(l);var e=C.getComputedStyle(l);n="1%"!==e.top,s=12===t(e.marginLeft),l.style.right="60%",o=36===t(e.right),r=36===t(e.width),l.style.position="absolute",i=12===t(l.offsetWidth/3),re.removeChild(u),l=null}}function t(e){return Math.round(parseFloat(e))}var n,r,i,o,a,s,u=E.createElement("div"),l=E.createElement("div");l.style&&(l.style.backgroundClip="content-box",l.cloneNode(!0).style.backgroundClip="",v.clearCloneStyle="content-box"===l.style.backgroundClip,S.extend(v,{boxSizingReliable:function(){return e(),r},pixelBoxStyles:function(){return e(),o},pixelPosition:function(){return e(),n},reliableMarginLeft:function(){return e(),s},scrollboxSize:function(){return e(),i},reliableTrDimensions:function(){var e,t,n,r;return null==a&&(e=E.createElement("table"),t=E.createElement("tr"),n=E.createElement("div"),e.style.cssText="position:absolute;left:-11111px;border-collapse:separate",t.style.cssText="border:1px solid",t.style.height="1px",n.style.height="9px",n.style.display="block",re.appendChild(e).appendChild(t).appendChild(n),r=C.getComputedStyle(t),a=parseInt(r.height,10)+parseInt(r.borderTopWidth,10)+parseInt(r.borderBottomWidth,10)===t.offsetHeight,re.removeChild(e)),a}}))}();var ze=["Webkit","Moz","ms"],Ue=E.createElement("div").style,Xe={};function Ve(e){var t=S.cssProps[e]||Xe[e];return t||(e in Ue?e:Xe[e]=function(e){var t=e[0].toUpperCase()+e.slice(1),n=ze.length;while(n--)if((e=ze[n]+t)in Ue)return e}(e)||e)}var Ge=/^(none|table(?!-c[ea]).+)/,Ye={position:"absolute",visibility:"hidden",display:"block"},Qe={letterSpacing:"0",fontWeight:"400"};function Je(e,t,n){var r=te.exec(t);return r?Math.max(0,r[2]-(n||0))+(r[3]||"px"):t}function Ke(e,t,n,r,i,o){var a="width"===t?1:0,s=0,u=0;if(n===(r?"border":"content"))return 0;for(;a<4;a+=2)"margin"===n&&(u+=S.css(e,n+ne[a],!0,i)),r?("content"===n&&(u-=S.css(e,"padding"+ne[a],!0,i)),"margin"!==n&&(u-=S.css(e,"border"+ne[a]+"Width",!0,i))):(u+=S.css(e,"padding"+ne[a],!0,i),"padding"!==n?u+=S.css(e,"border"+ne[a]+"Width",!0,i):s+=S.css(e,"border"+ne[a]+"Width",!0,i));return!r&&0<=o&&(u+=Math.max(0,Math.ceil(e["offset"+t[0].toUpperCase()+t.slice(1)]-o-u-s-.5))||0),u}function Ze(e,t,n){var r=Me(e),i=(!v.boxSizingReliable()||n)&&"border-box"===S.css(e,"boxSizing",!1,r),o=i,a=Be(e,t,r),s="offset"+t[0].toUpperCase()+t.slice(1);if(Pe.test(a)){if(!n)return a;a="auto"}return(!v.boxSizingReliable()&&i||!v.reliableTrDimensions()&&A(e,"tr")||"auto"===a||!parseFloat(a)&&"inline"===S.css(e,"display",!1,r))&&e.getClientRects().length&&(i="border-box"===S.css(e,"boxSizing",!1,r),(o=s in e)&&(a=e[s])),(a=parseFloat(a)||0)+Ke(e,t,n||(i?"border":"content"),o,r,a)+"px"}function et(e,t,n,r,i){return new et.prototype.init(e,t,n,r,i)}S.extend({cssHooks:{opacity:{get:function(e,t){if(t){var n=Be(e,"opacity");return""===n?"1":n}}}},cssNumber:{animationIterationCount:!0,columnCount:!0,fillOpacity:!0,flexGrow:!0,flexShrink:!0,fontWeight:!0,gridArea:!0,gridColumn:!0,gridColumnEnd:!0,gridColumnStart:!0,gridRow:!0,gridRowEnd:!0,gridRowStart:!0,lineHeight:!0,opacity:!0,order:!0,orphans:!0,widows:!0,zIndex:!0,zoom:!0},cssProps:{},style:function(e,t,n,r){if(e&&3!==e.nodeType&&8!==e.nodeType&&e.style){var i,o,a,s=X(t),u=Re.test(t),l=e.style;if(u||(t=Ve(s)),a=S.cssHooks[t]||S.cssHooks[s],void 0===n)return a&&"get"in a&&void 0!==(i=a.get(e,!1,r))?i:l[t];"string"===(o=typeof n)&&(i=te.exec(n))&&i[1]&&(n=se(e,t,i),o="number"),null!=n&&n==n&&("number"!==o||u||(n+=i&&i[3]||(S.cssNumber[s]?"":"px")),v.clearCloneStyle||""!==n||0!==t.indexOf("background")||(l[t]="inherit"),a&&"set"in a&&void 0===(n=a.set(e,n,r))||(u?l.setProperty(t,n):l[t]=n))}},css:function(e,t,n,r){var i,o,a,s=X(t);return Re.test(t)||(t=Ve(s)),(a=S.cssHooks[t]||S.cssHooks[s])&&"get"in a&&(i=a.get(e,!0,n)),void 0===i&&(i=Be(e,t,r)),"normal"===i&&t in Qe&&(i=Qe[t]),""===n||n?(o=parseFloat(i),!0===n||isFinite(o)?o||0:i):i}}),S.each(["height","width"],function(e,u){S.cssHooks[u]={get:function(e,t,n){if(t)return!Ge.test(S.css(e,"display"))||e.getClientRects().length&&e.getBoundingClientRect().width?Ze(e,u,n):Ie(e,Ye,function(){return Ze(e,u,n)})},set:function(e,t,n){var r,i=Me(e),o=!v.scrollboxSize()&&"absolute"===i.position,a=(o||n)&&"border-box"===S.css(e,"boxSizing",!1,i),s=n?Ke(e,u,n,a,i):0;return a&&o&&(s-=Math.ceil(e["offset"+u[0].toUpperCase()+u.slice(1)]-parseFloat(i[u])-Ke(e,u,"border",!1,i)-.5)),s&&(r=te.exec(t))&&"px"!==(r[3]||"px")&&(e.style[u]=t,t=S.css(e,u)),Je(0,t,s)}}}),S.cssHooks.marginLeft=_e(v.reliableMarginLeft,function(e,t){if(t)return(parseFloat(Be(e,"marginLeft"))||e.getBoundingClientRect().left-Ie(e,{marginLeft:0},function(){return e.getBoundingClientRect().left}))+"px"}),S.each({margin:"",padding:"",border:"Width"},function(i,o){S.cssHooks[i+o]={expand:function(e){for(var t=0,n={},r="string"==typeof e?e.split(" "):[e];t<4;t++)n[i+ne[t]+o]=r[t]||r[t-2]||r[0];return n}},"margin"!==i&&(S.cssHooks[i+o].set=Je)}),S.fn.extend({css:function(e,t){return B(this,function(e,t,n){var r,i,o={},a=0;if(Array.isArray(t)){for(r=Me(e),i=t.length;a<i;a++)o[t[a]]=S.css(e,t[a],!1,r);return o}return void 0!==n?S.style(e,t,n):S.css(e,t)},e,t,1<arguments.length)}}),((S.Tween=et).prototype={constructor:et,init:function(e,t,n,r,i,o){this.elem=e,this.prop=n,this.easing=i||S.easing._default,this.options=t,this.start=this.now=this.cur(),this.end=r,this.unit=o||(S.cssNumber[n]?"":"px")},cur:function(){var e=et.propHooks[this.prop];return e&&e.get?e.get(this):et.propHooks._default.get(this)},run:function(e){var t,n=et.propHooks[this.prop];return this.options.duration?this.pos=t=S.easing[this.easing](e,this.options.duration*e,0,1,this.options.duration):this.pos=t=e,this.now=(this.end-this.start)*t+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),n&&n.set?n.set(this):et.propHooks._default.set(this),this}}).init.prototype=et.prototype,(et.propHooks={_default:{get:function(e){var t;return 1!==e.elem.nodeType||null!=e.elem[e.prop]&&null==e.elem.style[e.prop]?e.elem[e.prop]:(t=S.css(e.elem,e.prop,""))&&"auto"!==t?t:0},set:function(e){S.fx.step[e.prop]?S.fx.step[e.prop](e):1!==e.elem.nodeType||!S.cssHooks[e.prop]&&null==e.elem.style[Ve(e.prop)]?e.elem[e.prop]=e.now:S.style(e.elem,e.prop,e.now+e.unit)}}}).scrollTop=et.propHooks.scrollLeft={set:function(e){e.elem.nodeType&&e.elem.parentNode&&(e.elem[e.prop]=e.now)}},S.easing={linear:function(e){return e},swing:function(e){return.5-Math.cos(e*Math.PI)/2},_default:"swing"},S.fx=et.prototype.init,S.fx.step={};var tt,nt,rt,it,ot=/^(?:toggle|show|hide)$/,at=/queueHooks$/;function st(){nt&&(!1===E.hidden&&C.requestAnimationFrame?C.requestAnimationFrame(st):C.setTimeout(st,S.fx.interval),S.fx.tick())}function ut(){return C.setTimeout(function(){tt=void 0}),tt=Date.now()}function lt(e,t){var n,r=0,i={height:e};for(t=t?1:0;r<4;r+=2-t)i["margin"+(n=ne[r])]=i["padding"+n]=e;return t&&(i.opacity=i.width=e),i}function ct(e,t,n){for(var r,i=(ft.tweeners[t]||[]).concat(ft.tweeners["*"]),o=0,a=i.length;o<a;o++)if(r=i[o].call(n,t,e))return r}function ft(o,e,t){var n,a,r=0,i=ft.prefilters.length,s=S.Deferred().always(function(){delete u.elem}),u=function(){if(a)return!1;for(var e=tt||ut(),t=Math.max(0,l.startTime+l.duration-e),n=1-(t/l.duration||0),r=0,i=l.tweens.length;r<i;r++)l.tweens[r].run(n);return s.notifyWith(o,[l,n,t]),n<1&&i?t:(i||s.notifyWith(o,[l,1,0]),s.resolveWith(o,[l]),!1)},l=s.promise({elem:o,props:S.extend({},e),opts:S.extend(!0,{specialEasing:{},easing:S.easing._default},t),originalProperties:e,originalOptions:t,startTime:tt||ut(),duration:t.duration,tweens:[],createTween:function(e,t){var n=S.Tween(o,l.opts,e,t,l.opts.specialEasing[e]||l.opts.easing);return l.tweens.push(n),n},stop:function(e){var t=0,n=e?l.tweens.length:0;if(a)return this;for(a=!0;t<n;t++)l.tweens[t].run(1);return e?(s.notifyWith(o,[l,1,0]),s.resolveWith(o,[l,e])):s.rejectWith(o,[l,e]),this}}),c=l.props;for(!function(e,t){var n,r,i,o,a;for(n in e)if(i=t[r=X(n)],o=e[n],Array.isArray(o)&&(i=o[1],o=e[n]=o[0]),n!==r&&(e[r]=o,delete e[n]),(a=S.cssHooks[r])&&"expand"in a)for(n in o=a.expand(o),delete e[r],o)n in e||(e[n]=o[n],t[n]=i);else t[r]=i}(c,l.opts.specialEasing);r<i;r++)if(n=ft.prefilters[r].call(l,o,c,l.opts))return m(n.stop)&&(S._queueHooks(l.elem,l.opts.queue).stop=n.stop.bind(n)),n;return S.map(c,ct,l),m(l.opts.start)&&l.opts.start.call(o,l),l.progress(l.opts.progress).done(l.opts.done,l.opts.complete).fail(l.opts.fail).always(l.opts.always),S.fx.timer(S.extend(u,{elem:o,anim:l,queue:l.opts.queue})),l}S.Animation=S.extend(ft,{tweeners:{"*":[function(e,t){var n=this.createTween(e,t);return se(n.elem,e,te.exec(t),n),n}]},tweener:function(e,t){m(e)?(t=e,e=["*"]):e=e.match(P);for(var n,r=0,i=e.length;r<i;r++)n=e[r],ft.tweeners[n]=ft.tweeners[n]||[],ft.tweeners[n].unshift(t)},prefilters:[function(e,t,n){var r,i,o,a,s,u,l,c,f="width"in t||"height"in t,p=this,d={},h=e.style,g=e.nodeType&&ae(e),y=Y.get(e,"fxshow");for(r in n.queue||(null==(a=S._queueHooks(e,"fx")).unqueued&&(a.unqueued=0,s=a.empty.fire,a.empty.fire=function(){a.unqueued||s()}),a.unqueued++,p.always(function(){p.always(function(){a.unqueued--,S.queue(e,"fx").length||a.empty.fire()})})),t)if(i=t[r],ot.test(i)){if(delete t[r],o=o||"toggle"===i,i===(g?"hide":"show")){if("show"!==i||!y||void 0===y[r])continue;g=!0}d[r]=y&&y[r]||S.style(e,r)}if((u=!S.isEmptyObject(t))||!S.isEmptyObject(d))for(r in f&&1===e.nodeType&&(n.overflow=[h.overflow,h.overflowX,h.overflowY],null==(l=y&&y.display)&&(l=Y.get(e,"display")),"none"===(c=S.css(e,"display"))&&(l?c=l:(le([e],!0),l=e.style.display||l,c=S.css(e,"display"),le([e]))),("inline"===c||"inline-block"===c&&null!=l)&&"none"===S.css(e,"float")&&(u||(p.done(function(){h.display=l}),null==l&&(c=h.display,l="none"===c?"":c)),h.display="inline-block")),n.overflow&&(h.overflow="hidden",p.always(function(){h.overflow=n.overflow[0],h.overflowX=n.overflow[1],h.overflowY=n.overflow[2]})),u=!1,d)u||(y?"hidden"in y&&(g=y.hidden):y=Y.access(e,"fxshow",{display:l}),o&&(y.hidden=!g),g&&le([e],!0),p.done(function(){for(r in g||le([e]),Y.remove(e,"fxshow"),d)S.style(e,r,d[r])})),u=ct(g?y[r]:0,r,p),r in y||(y[r]=u.start,g&&(u.end=u.start,u.start=0))}],prefilter:function(e,t){t?ft.prefilters.unshift(e):ft.prefilters.push(e)}}),S.speed=function(e,t,n){var r=e&&"object"==typeof e?S.extend({},e):{complete:n||!n&&t||m(e)&&e,duration:e,easing:n&&t||t&&!m(t)&&t};return S.fx.off?r.duration=0:"number"!=typeof r.duration&&(r.duration in S.fx.speeds?r.duration=S.fx.speeds[r.duration]:r.duration=S.fx.speeds._default),null!=r.queue&&!0!==r.queue||(r.queue="fx"),r.old=r.complete,r.complete=function(){m(r.old)&&r.old.call(this),r.queue&&S.dequeue(this,r.queue)},r},S.fn.extend({fadeTo:function(e,t,n,r){return this.filter(ae).css("opacity",0).show().end().animate({opacity:t},e,n,r)},animate:function(t,e,n,r){var i=S.isEmptyObject(t),o=S.speed(e,n,r),a=function(){var e=ft(this,S.extend({},t),o);(i||Y.get(this,"finish"))&&e.stop(!0)};return a.finish=a,i||!1===o.queue?this.each(a):this.queue(o.queue,a)},stop:function(i,e,o){var a=function(e){var t=e.stop;delete e.stop,t(o)};return"string"!=typeof i&&(o=e,e=i,i=void 0),e&&this.queue(i||"fx",[]),this.each(function(){var e=!0,t=null!=i&&i+"queueHooks",n=S.timers,r=Y.get(this);if(t)r[t]&&r[t].stop&&a(r[t]);else for(t in r)r[t]&&r[t].stop&&at.test(t)&&a(r[t]);for(t=n.length;t--;)n[t].elem!==this||null!=i&&n[t].queue!==i||(n[t].anim.stop(o),e=!1,n.splice(t,1));!e&&o||S.dequeue(this,i)})},finish:function(a){return!1!==a&&(a=a||"fx"),this.each(function(){var e,t=Y.get(this),n=t[a+"queue"],r=t[a+"queueHooks"],i=S.timers,o=n?n.length:0;for(t.finish=!0,S.queue(this,a,[]),r&&r.stop&&r.stop.call(this,!0),e=i.length;e--;)i[e].elem===this&&i[e].queue===a&&(i[e].anim.stop(!0),i.splice(e,1));for(e=0;e<o;e++)n[e]&&n[e].finish&&n[e].finish.call(this);delete t.finish})}}),S.each(["toggle","show","hide"],function(e,r){var i=S.fn[r];S.fn[r]=function(e,t,n){return null==e||"boolean"==typeof e?i.apply(this,arguments):this.animate(lt(r,!0),e,t,n)}}),S.each({slideDown:lt("show"),slideUp:lt("hide"),slideToggle:lt("toggle"),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"},fadeToggle:{opacity:"toggle"}},function(e,r){S.fn[e]=function(e,t,n){return this.animate(r,e,t,n)}}),S.timers=[],S.fx.tick=function(){var e,t=0,n=S.timers;for(tt=Date.now();t<n.length;t++)(e=n[t])()||n[t]!==e||n.splice(t--,1);n.length||S.fx.stop(),tt=void 0},S.fx.timer=function(e){S.timers.push(e),S.fx.start()},S.fx.interval=13,S.fx.start=function(){nt||(nt=!0,st())},S.fx.stop=function(){nt=null},S.fx.speeds={slow:600,fast:200,_default:400},S.fn.delay=function(r,e){return r=S.fx&&S.fx.speeds[r]||r,e=e||"fx",this.queue(e,function(e,t){var n=C.setTimeout(e,r);t.stop=function(){C.clearTimeout(n)}})},rt=E.createElement("input"),it=E.createElement("select").appendChild(E.createElement("option")),rt.type="checkbox",v.checkOn=""!==rt.value,v.optSelected=it.selected,(rt=E.createElement("input")).value="t",rt.type="radio",v.radioValue="t"===rt.value;var pt,dt=S.expr.attrHandle;S.fn.extend({attr:function(e,t){return B(this,S.attr,e,t,1<arguments.length)},removeAttr:function(e){return this.each(function(){S.removeAttr(this,e)})}}),S.extend({attr:function(e,t,n){var r,i,o=e.nodeType;if(3!==o&&8!==o&&2!==o)return"undefined"==typeof e.getAttribute?S.prop(e,t,n):(1===o&&S.isXMLDoc(e)||(i=S.attrHooks[t.toLowerCase()]||(S.expr.match.bool.test(t)?pt:void 0)),void 0!==n?null===n?void S.removeAttr(e,t):i&&"set"in i&&void 0!==(r=i.set(e,n,t))?r:(e.setAttribute(t,n+""),n):i&&"get"in i&&null!==(r=i.get(e,t))?r:null==(r=S.find.attr(e,t))?void 0:r)},attrHooks:{type:{set:function(e,t){if(!v.radioValue&&"radio"===t&&A(e,"input")){var n=e.value;return e.setAttribute("type",t),n&&(e.value=n),t}}}},removeAttr:function(e,t){var n,r=0,i=t&&t.match(P);if(i&&1===e.nodeType)while(n=i[r++])e.removeAttribute(n)}}),pt={set:function(e,t,n){return!1===t?S.removeAttr(e,n):e.setAttribute(n,n),n}},S.each(S.expr.match.bool.source.match(/\w+/g),function(e,t){var a=dt[t]||S.find.attr;dt[t]=function(e,t,n){var r,i,o=t.toLowerCase();return n||(i=dt[o],dt[o]=r,r=null!=a(e,t,n)?o:null,dt[o]=i),r}});var ht=/^(?:input|select|textarea|button)$/i,gt=/^(?:a|area)$/i;function yt(e){return(e.match(P)||[]).join(" ")}function vt(e){return e.getAttribute&&e.getAttribute("class")||""}function mt(e){return Array.isArray(e)?e:"string"==typeof e&&e.match(P)||[]}S.fn.extend({prop:function(e,t){return B(this,S.prop,e,t,1<arguments.length)},removeProp:function(e){return this.each(function(){delete this[S.propFix[e]||e]})}}),S.extend({prop:function(e,t,n){var r,i,o=e.nodeType;if(3!==o&&8!==o&&2!==o)return 1===o&&S.isXMLDoc(e)||(t=S.propFix[t]||t,i=S.propHooks[t]),void 0!==n?i&&"set"in i&&void 0!==(r=i.set(e,n,t))?r:e[t]=n:i&&"get"in i&&null!==(r=i.get(e,t))?r:e[t]},propHooks:{tabIndex:{get:function(e){var t=S.find.attr(e,"tabindex");return t?parseInt(t,10):ht.test(e.nodeName)||gt.test(e.nodeName)&&e.href?0:-1}}},propFix:{"for":"htmlFor","class":"className"}}),v.optSelected||(S.propHooks.selected={get:function(e){var t=e.parentNode;return t&&t.parentNode&&t.parentNode.selectedIndex,null},set:function(e){var t=e.parentNode;t&&(t.selectedIndex,t.parentNode&&t.parentNode.selectedIndex)}}),S.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){S.propFix[this.toLowerCase()]=this}),S.fn.extend({addClass:function(t){var e,n,r,i,o,a;return m(t)?this.each(function(e){S(this).addClass(t.call(this,e,vt(this)))}):(e=mt(t)).length?this.each(function(){if(r=vt(this),n=1===this.nodeType&&" "+yt(r)+" "){for(o=0;o<e.length;o++)i=e[o],n.indexOf(" "+i+" ")<0&&(n+=i+" ");a=yt(n),r!==a&&this.setAttribute("class",a)}}):this},removeClass:function(t){var e,n,r,i,o,a;return m(t)?this.each(function(e){S(this).removeClass(t.call(this,e,vt(this)))}):arguments.length?(e=mt(t)).length?this.each(function(){if(r=vt(this),n=1===this.nodeType&&" "+yt(r)+" "){for(o=0;o<e.length;o++){i=e[o];while(-1<n.indexOf(" "+i+" "))n=n.replace(" "+i+" "," ")}a=yt(n),r!==a&&this.setAttribute("class",a)}}):this:this.attr("class","")},toggleClass:function(t,n){var e,r,i,o,a=typeof t,s="string"===a||Array.isArray(t);return m(t)?this.each(function(e){S(this).toggleClass(t.call(this,e,vt(this),n),n)}):"boolean"==typeof n&&s?n?this.addClass(t):this.removeClass(t):(e=mt(t),this.each(function(){if(s)for(o=S(this),i=0;i<e.length;i++)r=e[i],o.hasClass(r)?o.removeClass(r):o.addClass(r);else void 0!==t&&"boolean"!==a||((r=vt(this))&&Y.set(this,"__className__",r),this.setAttribute&&this.setAttribute("class",r||!1===t?"":Y.get(this,"__className__")||""))}))},hasClass:function(e){var t,n,r=0;t=" "+e+" ";while(n=this[r++])if(1===n.nodeType&&-1<(" "+yt(vt(n))+" ").indexOf(t))return!0;return!1}});var xt=/\r/g;S.fn.extend({val:function(n){var r,e,i,t=this[0];return arguments.length?(i=m(n),this.each(function(e){var t;1===this.nodeType&&(null==(t=i?n.call(this,e,S(this).val()):n)?t="":"number"==typeof t?t+="":Array.isArray(t)&&(t=S.map(t,function(e){return null==e?"":e+""})),(r=S.valHooks[this.type]||S.valHooks[this.nodeName.toLowerCase()])&&"set"in r&&void 0!==r.set(this,t,"value")||(this.value=t))})):t?(r=S.valHooks[t.type]||S.valHooks[t.nodeName.toLowerCase()])&&"get"in r&&void 0!==(e=r.get(t,"value"))?e:"string"==typeof(e=t.value)?e.replace(xt,""):null==e?"":e:void 0}}),S.extend({valHooks:{option:{get:function(e){var t=S.find.attr(e,"value");return null!=t?t:yt(S.text(e))}},select:{get:function(e){var t,n,r,i=e.options,o=e.selectedIndex,a="select-one"===e.type,s=a?null:[],u=a?o+1:i.length;for(r=o<0?u:a?o:0;r<u;r++)if(((n=i[r]).selected||r===o)&&!n.disabled&&(!n.parentNode.disabled||!A(n.parentNode,"optgroup"))){if(t=S(n).val(),a)return t;s.push(t)}return s},set:function(e,t){var n,r,i=e.options,o=S.makeArray(t),a=i.length;while(a--)((r=i[a]).selected=-1<S.inArray(S.valHooks.option.get(r),o))&&(n=!0);return n||(e.selectedIndex=-1),o}}}}),S.each(["radio","checkbox"],function(){S.valHooks[this]={set:function(e,t){if(Array.isArray(t))return e.checked=-1<S.inArray(S(e).val(),t)}},v.checkOn||(S.valHooks[this].get=function(e){return null===e.getAttribute("value")?"on":e.value})}),v.focusin="onfocusin"in C;var bt=/^(?:focusinfocus|focusoutblur)$/,wt=function(e){e.stopPropagation()};S.extend(S.event,{trigger:function(e,t,n,r){var i,o,a,s,u,l,c,f,p=[n||E],d=y.call(e,"type")?e.type:e,h=y.call(e,"namespace")?e.namespace.split("."):[];if(o=f=a=n=n||E,3!==n.nodeType&&8!==n.nodeType&&!bt.test(d+S.event.triggered)&&(-1<d.indexOf(".")&&(d=(h=d.split(".")).shift(),h.sort()),u=d.indexOf(":")<0&&"on"+d,(e=e[S.expando]?e:new S.Event(d,"object"==typeof e&&e)).isTrigger=r?2:3,e.namespace=h.join("."),e.rnamespace=e.namespace?new RegExp("(^|\\.)"+h.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,e.result=void 0,e.target||(e.target=n),t=null==t?[e]:S.makeArray(t,[e]),c=S.event.special[d]||{},r||!c.trigger||!1!==c.trigger.apply(n,t))){if(!r&&!c.noBubble&&!x(n)){for(s=c.delegateType||d,bt.test(s+d)||(o=o.parentNode);o;o=o.parentNode)p.push(o),a=o;a===(n.ownerDocument||E)&&p.push(a.defaultView||a.parentWindow||C)}i=0;while((o=p[i++])&&!e.isPropagationStopped())f=o,e.type=1<i?s:c.bindType||d,(l=(Y.get(o,"events")||Object.create(null))[e.type]&&Y.get(o,"handle"))&&l.apply(o,t),(l=u&&o[u])&&l.apply&&V(o)&&(e.result=l.apply(o,t),!1===e.result&&e.preventDefault());return e.type=d,r||e.isDefaultPrevented()||c._default&&!1!==c._default.apply(p.pop(),t)||!V(n)||u&&m(n[d])&&!x(n)&&((a=n[u])&&(n[u]=null),S.event.triggered=d,e.isPropagationStopped()&&f.addEventListener(d,wt),n[d](),e.isPropagationStopped()&&f.removeEventListener(d,wt),S.event.triggered=void 0,a&&(n[u]=a)),e.result}},simulate:function(e,t,n){var r=S.extend(new S.Event,n,{type:e,isSimulated:!0});S.event.trigger(r,null,t)}}),S.fn.extend({trigger:function(e,t){return this.each(function(){S.event.trigger(e,t,this)})},triggerHandler:function(e,t){var n=this[0];if(n)return S.event.trigger(e,t,n,!0)}}),v.focusin||S.each({focus:"focusin",blur:"focusout"},function(n,r){var i=function(e){S.event.simulate(r,e.target,S.event.fix(e))};S.event.special[r]={setup:function(){var e=this.ownerDocument||this.document||this,t=Y.access(e,r);t||e.addEventListener(n,i,!0),Y.access(e,r,(t||0)+1)},teardown:function(){var e=this.ownerDocument||this.document||this,t=Y.access(e,r)-1;t?Y.access(e,r,t):(e.removeEventListener(n,i,!0),Y.remove(e,r))}}});var Tt=C.location,Ct={guid:Date.now()},Et=/\?/;S.parseXML=function(e){var t,n;if(!e||"string"!=typeof e)return null;try{t=(new C.DOMParser).parseFromString(e,"text/xml")}catch(e){}return n=t&&t.getElementsByTagName("parsererror")[0],t&&!n||S.error("Invalid XML: "+(n?S.map(n.childNodes,function(e){return e.textContent}).join("\n"):e)),t};var St=/\[\]$/,kt=/\r?\n/g,At=/^(?:submit|button|image|reset|file)$/i,Nt=/^(?:input|select|textarea|keygen)/i;function jt(n,e,r,i){var t;if(Array.isArray(e))S.each(e,function(e,t){r||St.test(n)?i(n,t):jt(n+"["+("object"==typeof t&&null!=t?e:"")+"]",t,r,i)});else if(r||"object"!==w(e))i(n,e);else for(t in e)jt(n+"["+t+"]",e[t],r,i)}S.param=function(e,t){var n,r=[],i=function(e,t){var n=m(t)?t():t;r[r.length]=encodeURIComponent(e)+"="+encodeURIComponent(null==n?"":n)};if(null==e)return"";if(Array.isArray(e)||e.jquery&&!S.isPlainObject(e))S.each(e,function(){i(this.name,this.value)});else for(n in e)jt(n,e[n],t,i);return r.join("&")},S.fn.extend({serialize:function(){return S.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var e=S.prop(this,"elements");return e?S.makeArray(e):this}).filter(function(){var e=this.type;return this.name&&!S(this).is(":disabled")&&Nt.test(this.nodeName)&&!At.test(e)&&(this.checked||!pe.test(e))}).map(function(e,t){var n=S(this).val();return null==n?null:Array.isArray(n)?S.map(n,function(e){return{name:t.name,value:e.replace(kt,"\r\n")}}):{name:t.name,value:n.replace(kt,"\r\n")}}).get()}});var Dt=/%20/g,qt=/#.*$/,Lt=/([?&])_=[^&]*/,Ht=/^(.*?):[ \t]*([^\r\n]*)$/gm,Ot=/^(?:GET|HEAD)$/,Pt=/^\/\//,Rt={},Mt={},It="*/".concat("*"),Wt=E.createElement("a");function Ft(o){return function(e,t){"string"!=typeof e&&(t=e,e="*");var n,r=0,i=e.toLowerCase().match(P)||[];if(m(t))while(n=i[r++])"+"===n[0]?(n=n.slice(1)||"*",(o[n]=o[n]||[]).unshift(t)):(o[n]=o[n]||[]).push(t)}}function $t(t,i,o,a){var s={},u=t===Mt;function l(e){var r;return s[e]=!0,S.each(t[e]||[],function(e,t){var n=t(i,o,a);return"string"!=typeof n||u||s[n]?u?!(r=n):void 0:(i.dataTypes.unshift(n),l(n),!1)}),r}return l(i.dataTypes[0])||!s["*"]&&l("*")}function Bt(e,t){var n,r,i=S.ajaxSettings.flatOptions||{};for(n in t)void 0!==t[n]&&((i[n]?e:r||(r={}))[n]=t[n]);return r&&S.extend(!0,e,r),e}Wt.href=Tt.href,S.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:Tt.href,type:"GET",isLocal:/^(?:about|app|app-storage|.+-extension|file|res|widget):$/.test(Tt.protocol),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":It,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/\bxml\b/,html:/\bhtml/,json:/\bjson\b/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":JSON.parse,"text xml":S.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(e,t){return t?Bt(Bt(e,S.ajaxSettings),t):Bt(S.ajaxSettings,e)},ajaxPrefilter:Ft(Rt),ajaxTransport:Ft(Mt),ajax:function(e,t){"object"==typeof e&&(t=e,e=void 0),t=t||{};var c,f,p,n,d,r,h,g,i,o,y=S.ajaxSetup({},t),v=y.context||y,m=y.context&&(v.nodeType||v.jquery)?S(v):S.event,x=S.Deferred(),b=S.Callbacks("once memory"),w=y.statusCode||{},a={},s={},u="canceled",T={readyState:0,getResponseHeader:function(e){var t;if(h){if(!n){n={};while(t=Ht.exec(p))n[t[1].toLowerCase()+" "]=(n[t[1].toLowerCase()+" "]||[]).concat(t[2])}t=n[e.toLowerCase()+" "]}return null==t?null:t.join(", ")},getAllResponseHeaders:function(){return h?p:null},setRequestHeader:function(e,t){return null==h&&(e=s[e.toLowerCase()]=s[e.toLowerCase()]||e,a[e]=t),this},overrideMimeType:function(e){return null==h&&(y.mimeType=e),this},statusCode:function(e){var t;if(e)if(h)T.always(e[T.status]);else for(t in e)w[t]=[w[t],e[t]];return this},abort:function(e){var t=e||u;return c&&c.abort(t),l(0,t),this}};if(x.promise(T),y.url=((e||y.url||Tt.href)+"").replace(Pt,Tt.protocol+"//"),y.type=t.method||t.type||y.method||y.type,y.dataTypes=(y.dataType||"*").toLowerCase().match(P)||[""],null==y.crossDomain){r=E.createElement("a");try{r.href=y.url,r.href=r.href,y.crossDomain=Wt.protocol+"//"+Wt.host!=r.protocol+"//"+r.host}catch(e){y.crossDomain=!0}}if(y.data&&y.processData&&"string"!=typeof y.data&&(y.data=S.param(y.data,y.traditional)),$t(Rt,y,t,T),h)return T;for(i in(g=S.event&&y.global)&&0==S.active++&&S.event.trigger("ajaxStart"),y.type=y.type.toUpperCase(),y.hasContent=!Ot.test(y.type),f=y.url.replace(qt,""),y.hasContent?y.data&&y.processData&&0===(y.contentType||"").indexOf("application/x-www-form-urlencoded")&&(y.data=y.data.replace(Dt,"+")):(o=y.url.slice(f.length),y.data&&(y.processData||"string"==typeof y.data)&&(f+=(Et.test(f)?"&":"?")+y.data,delete y.data),!1===y.cache&&(f=f.replace(Lt,"$1"),o=(Et.test(f)?"&":"?")+"_="+Ct.guid+++o),y.url=f+o),y.ifModified&&(S.lastModified[f]&&T.setRequestHeader("If-Modified-Since",S.lastModified[f]),S.etag[f]&&T.setRequestHeader("If-None-Match",S.etag[f])),(y.data&&y.hasContent&&!1!==y.contentType||t.contentType)&&T.setRequestHeader("Content-Type",y.contentType),T.setRequestHeader("Accept",y.dataTypes[0]&&y.accepts[y.dataTypes[0]]?y.accepts[y.dataTypes[0]]+("*"!==y.dataTypes[0]?", "+It+"; q=0.01":""):y.accepts["*"]),y.headers)T.setRequestHeader(i,y.headers[i]);if(y.beforeSend&&(!1===y.beforeSend.call(v,T,y)||h))return T.abort();if(u="abort",b.add(y.complete),T.done(y.success),T.fail(y.error),c=$t(Mt,y,t,T)){if(T.readyState=1,g&&m.trigger("ajaxSend",[T,y]),h)return T;y.async&&0<y.timeout&&(d=C.setTimeout(function(){T.abort("timeout")},y.timeout));try{h=!1,c.send(a,l)}catch(e){if(h)throw e;l(-1,e)}}else l(-1,"No Transport");function l(e,t,n,r){var i,o,a,s,u,l=t;h||(h=!0,d&&C.clearTimeout(d),c=void 0,p=r||"",T.readyState=0<e?4:0,i=200<=e&&e<300||304===e,n&&(s=function(e,t,n){var r,i,o,a,s=e.contents,u=e.dataTypes;while("*"===u[0])u.shift(),void 0===r&&(r=e.mimeType||t.getResponseHeader("Content-Type"));if(r)for(i in s)if(s[i]&&s[i].test(r)){u.unshift(i);break}if(u[0]in n)o=u[0];else{for(i in n){if(!u[0]||e.converters[i+" "+u[0]]){o=i;break}a||(a=i)}o=o||a}if(o)return o!==u[0]&&u.unshift(o),n[o]}(y,T,n)),!i&&-1<S.inArray("script",y.dataTypes)&&S.inArray("json",y.dataTypes)<0&&(y.converters["text script"]=function(){}),s=function(e,t,n,r){var i,o,a,s,u,l={},c=e.dataTypes.slice();if(c[1])for(a in e.converters)l[a.toLowerCase()]=e.converters[a];o=c.shift();while(o)if(e.responseFields[o]&&(n[e.responseFields[o]]=t),!u&&r&&e.dataFilter&&(t=e.dataFilter(t,e.dataType)),u=o,o=c.shift())if("*"===o)o=u;else if("*"!==u&&u!==o){if(!(a=l[u+" "+o]||l["* "+o]))for(i in l)if((s=i.split(" "))[1]===o&&(a=l[u+" "+s[0]]||l["* "+s[0]])){!0===a?a=l[i]:!0!==l[i]&&(o=s[0],c.unshift(s[1]));break}if(!0!==a)if(a&&e["throws"])t=a(t);else try{t=a(t)}catch(e){return{state:"parsererror",error:a?e:"No conversion from "+u+" to "+o}}}return{state:"success",data:t}}(y,s,T,i),i?(y.ifModified&&((u=T.getResponseHeader("Last-Modified"))&&(S.lastModified[f]=u),(u=T.getResponseHeader("etag"))&&(S.etag[f]=u)),204===e||"HEAD"===y.type?l="nocontent":304===e?l="notmodified":(l=s.state,o=s.data,i=!(a=s.error))):(a=l,!e&&l||(l="error",e<0&&(e=0))),T.status=e,T.statusText=(t||l)+"",i?x.resolveWith(v,[o,l,T]):x.rejectWith(v,[T,l,a]),T.statusCode(w),w=void 0,g&&m.trigger(i?"ajaxSuccess":"ajaxError",[T,y,i?o:a]),b.fireWith(v,[T,l]),g&&(m.trigger("ajaxComplete",[T,y]),--S.active||S.event.trigger("ajaxStop")))}return T},getJSON:function(e,t,n){return S.get(e,t,n,"json")},getScript:function(e,t){return S.get(e,void 0,t,"script")}}),S.each(["get","post"],function(e,i){S[i]=function(e,t,n,r){return m(t)&&(r=r||n,n=t,t=void 0),S.ajax(S.extend({url:e,type:i,dataType:r,data:t,success:n},S.isPlainObject(e)&&e))}}),S.ajaxPrefilter(function(e){var t;for(t in e.headers)"content-type"===t.toLowerCase()&&(e.contentType=e.headers[t]||"")}),S._evalUrl=function(e,t,n){return S.ajax({url:e,type:"GET",dataType:"script",cache:!0,async:!1,global:!1,converters:{"text script":function(){}},dataFilter:function(e){S.globalEval(e,t,n)}})},S.fn.extend({wrapAll:function(e){var t;return this[0]&&(m(e)&&(e=e.call(this[0])),t=S(e,this[0].ownerDocument).eq(0).clone(!0),this[0].parentNode&&t.insertBefore(this[0]),t.map(function(){var e=this;while(e.firstElementChild)e=e.firstElementChild;return e}).append(this)),this},wrapInner:function(n){return m(n)?this.each(function(e){S(this).wrapInner(n.call(this,e))}):this.each(function(){var e=S(this),t=e.contents();t.length?t.wrapAll(n):e.append(n)})},wrap:function(t){var n=m(t);return this.each(function(e){S(this).wrapAll(n?t.call(this,e):t)})},unwrap:function(e){return this.parent(e).not("body").each(function(){S(this).replaceWith(this.childNodes)}),this}}),S.expr.pseudos.hidden=function(e){return!S.expr.pseudos.visible(e)},S.expr.pseudos.visible=function(e){return!!(e.offsetWidth||e.offsetHeight||e.getClientRects().length)},S.ajaxSettings.xhr=function(){try{return new C.XMLHttpRequest}catch(e){}};var _t={0:200,1223:204},zt=S.ajaxSettings.xhr();v.cors=!!zt&&"withCredentials"in zt,v.ajax=zt=!!zt,S.ajaxTransport(function(i){var o,a;if(v.cors||zt&&!i.crossDomain)return{send:function(e,t){var n,r=i.xhr();if(r.open(i.type,i.url,i.async,i.username,i.password),i.xhrFields)for(n in i.xhrFields)r[n]=i.xhrFields[n];for(n in i.mimeType&&r.overrideMimeType&&r.overrideMimeType(i.mimeType),i.crossDomain||e["X-Requested-With"]||(e["X-Requested-With"]="XMLHttpRequest"),e)r.setRequestHeader(n,e[n]);o=function(e){return function(){o&&(o=a=r.onload=r.onerror=r.onabort=r.ontimeout=r.onreadystatechange=null,"abort"===e?r.abort():"error"===e?"number"!=typeof r.status?t(0,"error"):t(r.status,r.statusText):t(_t[r.status]||r.status,r.statusText,"text"!==(r.responseType||"text")||"string"!=typeof r.responseText?{binary:r.response}:{text:r.responseText},r.getAllResponseHeaders()))}},r.onload=o(),a=r.onerror=r.ontimeout=o("error"),void 0!==r.onabort?r.onabort=a:r.onreadystatechange=function(){4===r.readyState&&C.setTimeout(function(){o&&a()})},o=o("abort");try{r.send(i.hasContent&&i.data||null)}catch(e){if(o)throw e}},abort:function(){o&&o()}}}),S.ajaxPrefilter(function(e){e.crossDomain&&(e.contents.script=!1)}),S.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/\b(?:java|ecma)script\b/},converters:{"text script":function(e){return S.globalEval(e),e}}}),S.ajaxPrefilter("script",function(e){void 0===e.cache&&(e.cache=!1),e.crossDomain&&(e.type="GET")}),S.ajaxTransport("script",function(n){var r,i;if(n.crossDomain||n.scriptAttrs)return{send:function(e,t){r=S("<script>").attr(n.scriptAttrs||{}).prop({charset:n.scriptCharset,src:n.url}).on("load error",i=function(e){r.remove(),i=null,e&&t("error"===e.type?404:200,e.type)}),E.head.appendChild(r[0])},abort:function(){i&&i()}}});var Ut,Xt=[],Vt=/(=)\?(?=&|$)|\?\?/;S.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var e=Xt.pop()||S.expando+"_"+Ct.guid++;return this[e]=!0,e}}),S.ajaxPrefilter("json jsonp",function(e,t,n){var r,i,o,a=!1!==e.jsonp&&(Vt.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&Vt.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=m(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(Vt,"$1"+r):!1!==e.jsonp&&(e.url+=(Et.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return o||S.error(r+" was not called"),o[0]},e.dataTypes[0]="json",i=C[r],C[r]=function(){o=arguments},n.always(function(){void 0===i?S(C).removeProp(r):C[r]=i,e[r]&&(e.jsonpCallback=t.jsonpCallback,Xt.push(r)),o&&m(i)&&i(o[0]),o=i=void 0}),"script"}),v.createHTMLDocument=((Ut=E.implementation.createHTMLDocument("").body).innerHTML="<form></form><form></form>",2===Ut.childNodes.length),S.parseHTML=function(e,t,n){return"string"!=typeof e?[]:("boolean"==typeof t&&(n=t,t=!1),t||(v.createHTMLDocument?((r=(t=E.implementation.createHTMLDocument("")).createElement("base")).href=E.location.href,t.head.appendChild(r)):t=E),o=!n&&[],(i=N.exec(e))?[t.createElement(i[1])]:(i=xe([e],t,o),o&&o.length&&S(o).remove(),S.merge([],i.childNodes)));var r,i,o},S.fn.load=function(e,t,n){var r,i,o,a=this,s=e.indexOf(" ");return-1<s&&(r=yt(e.slice(s)),e=e.slice(0,s)),m(t)?(n=t,t=void 0):t&&"object"==typeof t&&(i="POST"),0<a.length&&S.ajax({url:e,type:i||"GET",dataType:"html",data:t}).done(function(e){o=arguments,a.html(r?S("<div>").append(S.parseHTML(e)).find(r):e)}).always(n&&function(e,t){a.each(function(){n.apply(this,o||[e.responseText,t,e])})}),this},S.expr.pseudos.animated=function(t){return S.grep(S.timers,function(e){return t===e.elem}).length},S.offset={setOffset:function(e,t,n){var r,i,o,a,s,u,l=S.css(e,"position"),c=S(e),f={};"static"===l&&(e.style.position="relative"),s=c.offset(),o=S.css(e,"top"),u=S.css(e,"left"),("absolute"===l||"fixed"===l)&&-1<(o+u).indexOf("auto")?(a=(r=c.position()).top,i=r.left):(a=parseFloat(o)||0,i=parseFloat(u)||0),m(t)&&(t=t.call(e,n,S.extend({},s))),null!=t.top&&(f.top=t.top-s.top+a),null!=t.left&&(f.left=t.left-s.left+i),"using"in t?t.using.call(e,f):c.css(f)}},S.fn.extend({offset:function(t){if(arguments.length)return void 0===t?this:this.each(function(e){S.offset.setOffset(this,t,e)});var e,n,r=this[0];return r?r.getClientRects().length?(e=r.getBoundingClientRect(),n=r.ownerDocument.defaultView,{top:e.top+n.pageYOffset,left:e.left+n.pageXOffset}):{top:0,left:0}:void 0},position:function(){if(this[0]){var e,t,n,r=this[0],i={top:0,left:0};if("fixed"===S.css(r,"position"))t=r.getBoundingClientRect();else{t=this.offset(),n=r.ownerDocument,e=r.offsetParent||n.documentElement;while(e&&(e===n.body||e===n.documentElement)&&"static"===S.css(e,"position"))e=e.parentNode;e&&e!==r&&1===e.nodeType&&((i=S(e).offset()).top+=S.css(e,"borderTopWidth",!0),i.left+=S.css(e,"borderLeftWidth",!0))}return{top:t.top-i.top-S.css(r,"marginTop",!0),left:t.left-i.left-S.css(r,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){var e=this.offsetParent;while(e&&"static"===S.css(e,"position"))e=e.offsetParent;return e||re})}}),S.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,i){var o="pageYOffset"===i;S.fn[t]=function(e){return B(this,function(e,t,n){var r;if(x(e)?r=e:9===e.nodeType&&(r=e.defaultView),void 0===n)return r?r[i]:e[t];r?r.scrollTo(o?r.pageXOffset:n,o?n:r.pageYOffset):e[t]=n},t,e,arguments.length)}}),S.each(["top","left"],function(e,n){S.cssHooks[n]=_e(v.pixelPosition,function(e,t){if(t)return t=Be(e,n),Pe.test(t)?S(e).position()[n]+"px":t})}),S.each({Height:"height",Width:"width"},function(a,s){S.each({padding:"inner"+a,content:s,"":"outer"+a},function(r,o){S.fn[o]=function(e,t){var n=arguments.length&&(r||"boolean"!=typeof e),i=r||(!0===e||!0===t?"margin":"border");return B(this,function(e,t,n){var r;return x(e)?0===o.indexOf("outer")?e["inner"+a]:e.document.documentElement["client"+a]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+a],r["scroll"+a],e.body["offset"+a],r["offset"+a],r["client"+a])):void 0===n?S.css(e,t,i):S.style(e,t,n,i)},s,n?e:void 0,n)}})}),S.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(e,t){S.fn[t]=function(e){return this.on(t,e)}}),S.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,"**"):this.off(t,e||"**",n)},hover:function(e,t){return this.mouseenter(e).mouseleave(t||e)}}),S.each("blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu".split(" "),function(e,n){S.fn[n]=function(e,t){return 0<arguments.length?this.on(n,null,e,t):this.trigger(n)}});var Gt=/^[\s\uFEFF\xA0]+|([^\s\uFEFF\xA0])[\s\uFEFF\xA0]+$/g;S.proxy=function(e,t){var n,r,i;if("string"==typeof t&&(n=e[t],t=e,e=n),m(e))return r=s.call(arguments,2),(i=function(){return e.apply(t||this,r.concat(s.call(arguments)))}).guid=e.guid=e.guid||S.guid++,i},S.holdReady=function(e){e?S.readyWait++:S.ready(!0)},S.isArray=Array.isArray,S.parseJSON=JSON.parse,S.nodeName=A,S.isFunction=m,S.isWindow=x,S.camelCase=X,S.type=w,S.now=Date.now,S.isNumeric=function(e){var t=S.type(e);return("number"===t||"string"===t)&&!isNaN(e-parseFloat(e))},S.trim=function(e){return null==e?"":(e+"").replace(Gt,"$1")},"function"==typeof define&&define.amd&&define("jquery",[],function(){return S});var Yt=C.jQuery,Qt=C.$;return S.noConflict=function(e){return C.$===S&&(C.$=Qt),e&&C.jQuery===S&&(C.jQuery=Yt),S},"undefined"==typeof e&&(C.jQuery=C.$=S),S});