diff -r c8698ce1e327 -r 415fdd210677 Develop/GSoC.content
--- a/Develop/GSoC.content	Thu Mar 28 17:33:24 2013 +0900
+++ b/Develop/GSoC.content	Mon Aug 19 17:04:06 2013 +0900
@@ -19,6 +19,72 @@
 
   <h2>XEmacs Plans and Policies</h2>
 
-  <p>This page is a placeholder; more content will be added Real Soon Now.
-    (Just kidding; there should be more <em>tomorrow</em>, and even more
-    the day after!  Please check again soon.)</p>
+  <p>Please refer to the <a href="index.html">XEmacs developers' page</a>
+    for information about XEmacs' development practices and developer
+    resources.</p>
+
+  <p>The following policies are somewhat tentative (and the writing is
+    stuffy and hard to understand).  They probably will be revised a
+    few times before coding starts.  Please check again soon.</p>
+
+  <ol>
+  <li><p>Interns are expected to complete a project of up to 2
+    man-months.</p></li>
+  <li><p>"Complete" means documenting requirements and design,
+    coding, creating unit tests, and end-user documentation.  Scope
+    of the proposal should be considered with those desiderata in
+    mind.</p></li>
+  <li><p>Interns are expected to engage with the community throughout
+    the project.  Note that this is just a restatement of one of
+    Google's goals for the Summer of Code program.  They are welcome
+    to consult potential mentors, other developers, and users in
+    developing proposals.  Note that currently the primary channel for
+    developer interaction is the XEmacs
+    Contributors mailing list &lt;xemacs-beta@xemacs.org&gt;.  XEmacs
+    will also advertise the intern's blog and social media as
+    available where the intern prefers those media.</p>
+    <ul>
+      <li><p>Besides communication about
+        specific issues encountered in the project, a weekly activity
+        report to the mailing list is required.  (It's required as a
+        way of allowing the
+        organization administrator and the mentors to quickly check for
+        communication problems and address them early.  But the
+        required weekly report can be
+        just a very short summary of what you've worked on.)</p></li>
+    </ul></li>
+  <li><p>Interns are considered to be professional colleagues.</p>
+    <p>That is, they
+    are expected to take initiative in engaging the community,
+    reporting on progress, and asking for help with problems.  On the
+    other hand, this also means that the Summer of Code is not a test.
+    In Summer of Code, asking for help is not "cheating".  Similarly,
+    mentors are
+    expected to treat interns as professionals, allowing students to
+    wrestle with problems that they should be able to solve, but also
+    providing help and information where that is the most effective
+    way to proceed.</p>
+    <p>Interns are expected to write their own code, documentation,
+    tests, and so on.  Contributions from third parties are not
+    strictly forbidden, but <em>must</em> be clearly documented, and
+    they <em>do not</em> count toward completion of the project.
+    Violations will be treated severely.</li>
+  <li><p>Both the intern and mentor are required to make an interim
+    progress report to the organization administrator one week before
+    each evaluation period opens.  The purpose is to allow the
+    administrator to intervene before evaluations are made in cases
+    where the intern and the mentor have very different perceptions of
+    the status of the project.</p></li>
+  <li><p>Google has made it plain that Google Summer of Code is
+    specifically about developing code, and may not be generalized to
+    software development in general such as documentation.
+    Accordingly, interns will be primarily evaluated on whether they
+    have delivered the code they proposed, with consideration for
+    unforeseen implementation difficulties.</p>
+    <p>However, interns should remember that in evaluating whether the
+    promised code was delivered, clear requirements and other
+    documentation, as well as passing unit tests, are crucial in
+    making an objective evaluation.  If the mentor and the intern
+    disagree about what the requirements were, and they are ambiguous,
+    it will be very hard to appeal an adverse decision.</p></li>
+  </ol>
diff -r c8698ce1e327 -r 415fdd210677 Develop/GSoC2013.content
--- a/Develop/GSoC2013.content	Thu Mar 28 17:33:24 2013 +0900
+++ b/Develop/GSoC2013.content	Mon Aug 19 17:04:06 2013 +0900
@@ -8,22 +8,114 @@
 
   <h2>for Google Summer of Code 2013</h2>
 
-  <p>This is the XEmacs <em>Ideas Page</em> for Google Summer of
-    Code 2013.</p>
-  <p>Please refer to the <a href="index.html">developers' page</a>
+  <p>Please refer to the <a href="index.html">XEmacs developers' page</a>
     for more information about our development process and
     resources for developers.</p>
+  <p>For advice about implementation of your project, whether one of
+    our suggestions or an original proposal, post to the
+    <a href="mailto:xemacs-beta@xemacs.org">XEmacs Contributors list
+    &lt;xemacs-beta@xemacs.org&gt;</a>.</p>
   <p>So you can get to the ideas as quickly as possible, we have a
-    separate page for XEmacs-specific <a href"GSoC.html">Summer of
+    separate page for XEmacs-specific <a href="GSoC.html">Summer of
     Code policies and plans</a>.  That page also contains references
     to specifications for accepted projects and proposals under
-    consideration -- please check those before making a proposal.  Do
-    feel free to consult the <a href="mailto:xemacs-beta@xemacs.org">
-    developer community</a> if your idea seems to overlap another
-    proposal before abandoning it.
-  <p>Aside from the explicit ideas listed below, we are of course
+    consideration -- please check those before making a proposal.  If
+    your idea seems to overlap another proposal, please do
+    consult the <a href="mailto:xemacs-beta@xemacs.org">
+    developer community</a> before abandoning it.
+  <p>And without further ado, our ideas.  Happy hacking!</p>
+
+  <h2 id="idea-list">The Idea List</h2>
+
+  <ol>
+  <li><p>Add lexical scope support as in GNU Emacs.  Compatibility
+    with GNU Emacs syntax and semantics is essential, but internal
+    implementation is likely to differ substantially.</p>
+    <p>Language: XEmacs Lisp, some C.</p></li>
+  <li><p>XEmacs sound support is gradually bit-rotting.  It was
+    written at a time when the only formats reliably supported were
+    "raw" audio streams.  Modern sound libraries are far more capable;
+    the XEmacs facilities should be generalized to delegate more work
+    to those libraries when possible.  On the other hand, XEmacs does
+    support extracting audio streams from compound file formats like
+    MIME mail messages.  Appropriate validation is required for such
+    streams.</p>
+    <ol>
+      <li><p>Update the sound support for modern ALSA on Linux
+        and similar systems.</p></li>
+      <li><p>Fix the non-blocking sound support.</p></li>
+    </ol>
+    <p>Language: C.</p>
+  <li><p>Finish the Qt port of XEmacs.  Adding support for embedding
+    XEmacs as a widget (KPart) in KDE applications is highly desirable.</p>
+    <p>Language: C, C++.</p></li>
+  <li><p>Develop a Cocoa port of XEmacs.  This may be "too large",
+    but based on past experience with X11-based GUIs and the aborted
+    Carbon port, it should be possible.  XEmacs "consoles" are quite
+    modular, with a well-defined set of routines that need to be
+    implemented to interface to a new GUI library.  Also, much code
+    can probably be adapted from GNU Emacs's Mac and NeXTStep ports.</p>
+    <p>Language: C, Objective-C.</p></li>
+  <li><p>Convert the XEmacs internal text representation to Unicode.
+    In general, most of the work for conversion to UTF-8 is already
+    done, as the traditional "MULE" encoding used internally is
+    formally very similar to UTF-8 (eg, it is ASCII-compatible, and
+    the first byte encodes the length of each character in bytes).
+    <p>This applies to editing buffers and strings.</p>
+    <p>Language: C.</p></li>
+  <li><p>Convert the XEmacs internal buffer representation to fixed-width,
+    but adapting to the range of characters actually present in the
+    buffer.  That is, text using only the ASCII and Latin-1 character
+    sets would be 8 bits wide, text using only characters from the BMP
+    would be 16 bits wide, and text using other planes of the Unicode
+    code set would be 32 bits wide.</p>
+    <p>Conversions of string format is desirable as well.  However,
+    the entire C code base will need to be analyzed for cases where
+    "internal" strings that happen to be all-ASCII are passed directly
+    to external libraries or the OS, as wide-format strings will
+    contain many null bytes that such libraries will incorrectly
+    interpret as string terminators.
+    <p>You may refer to <a href="http://www.python.org/dev/peps/pep-0393/">
+    PEP 393 -- Flexible String Representation</a>, Python's specification
+    for a similar feature.</p>
+    <p>Language: C.</p></li>
+  </ol>
+
+  <p>The following ideas are important to XEmacs, but we haven't
+  thought carefully about the amount of work involved.  Each one
+  individually may be
+  insufficient for Google Summer of Code projects.  Especially for
+  the Lisp porting projects, it may be possible to combine several
+  related ports into a single project.  Also, most areas of XEmacs
+  have insufficient tests, and that's even more true of GNU Emacs.</p>
+
+  <ol>
+  <li><p>Port SMIE from GNU Emacs.</p>
+    <p>Language: XEmacs Lisp.</p></li>
+  <li><p>Port the org-mode trunk to XEmacs package format.</p>
+    <p>Language: XEmacs Lisp.</p></li>
+  <li><p>Port the VM mailreader trunk to XEmacs package format.</p>
+    <p>Language: XEmacs Lisp.</p></li>
+  <li><p>Port the AUCTeX (and preview-latex) trunk to XEmacs package
+    format.</p>
+    <p>Language: XEmacs Lisp, some C.</p></li>
+  <li><p>Improve support for commit logs vs. ChangeLog files.  For
+    example, make C-x 4 a do something useful for projects that don't
+    use ChangeLogs.  This also requires figuring out how to serialize
+    commit logs in a useful way, since ChangeLog files are often used
+    precisely because they do linearize the changes.</p>
+    <p>Language: XEmacs Lisp.</p></li>
+  <li><p>Port Emacs' jit-lock to XEmacs.</p>
+    <p>Language: XEmacs Lisp, some C.</p></li>
+  </ol>
+
+  <p>Aside from the explicit ideas listed above, we are
     open to original proposals from students, of appropriate scale
-    for the Summer of Code.  For inspiration, we recommend these
+    for the Summer of Code.
+  <p>Of course, we always need more porting of GNU Emacs features.
+    However, usually this is not too difficult, so they may not make
+    very good proposals.</p>
+  <p>For inspiration, we recommend these
     resources by past designers of XEmacs:</p>
   <ol>
     <li><p><a href="<!-- _GP_ relPath(qq{Architecting-XEmacs/index.html}) -->">
@@ -33,23 +125,3 @@
   </ol>
   <p>(Note that these pages describe features that may require too little
     or too much code to be appropriate for Google Summer of Code.)
-  <p>And without further ado, our ideas.  Happy hacking!</p>
-
-  <h2 id="idea-list">The Idea List</h2>
-
-  <p>The following list is incomplete; please recheck for new ideas
-    or more information about existing ones.</p>
-
-  <ol>
-  <li><p>Convert the XEmacs internal text representation to Unicode.
-    This applies to buffers and strings.</p></li>
-  <li><p>Convert the XEmacs internal buffer representation to fixed-width,
-    but adapting to the range of characters actually present in the
-    buffer.  That is, text using only the ASCII and Latin-1 character
-    sets would be 8 bits wide, text using only characters from the BMP
-    would be 16 bits wide, and text using other planes of the Unicode
-    code set would be 32 bits wide.</p>
-    <p>You may refer to <a href="http://www.python.org/dev/peps/pep-0393/">
-    PEP 393 -- Flexible String Representation</a>, Python's specification
-    for a similar feature.</p></li>
-  </ol>
diff -r c8698ce1e327 -r 415fdd210677 Develop/index.content
--- a/Develop/index.content	Thu Mar 28 17:33:24 2013 +0900
+++ b/Develop/index.content	Mon Aug 19 17:04:06 2013 +0900
@@ -11,7 +11,11 @@
   <p>Currently enrolled students should consider applying to
     <a href="http://google-melange.com/">Google Summer of Code</a> for
     an internship on an <a href="GSoC.html">XEmacs project</a>  The
-    application period for 2013 is April 22 -- May 3.
+    application period for 2013 is April 22 -- May 3, but candidates
+    are encouraged to contact us at any time.  <em>Earlier is
+    better,</em> because community-building is an explicit goal of the
+    Summer of Code.  Active participation in XEmacs development is a
+    more important criterion than your current skill set!</p>
 
   <p>
     If you'd like to help with the XEmacs development effort, do the
