XEmacs and Google Summer of Code

Are you looking for the XEmacs Ideas Page? It's right over here.

Accepted projects for Summer of Code 2013

None yet.

Proposed projects for Summer of Code 2013

None yet.

XEmacs Plans and Policies

Please refer to the XEmacs developers' page for information about XEmacs' development practices and developer resources.

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.

Interns are expected to complete a project of up to 2 man-months.
"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.
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 <xemacs-beta@xemacs.org>. XEmacs will also advertise the intern's blog and social media as available where the intern prefers those media.
- 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.)
Interns are considered to be professional colleagues.

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.

Interns are expected to write their own code, documentation, tests, and so on. Contributions from third parties are not strictly forbidden, but must be clearly documented, and they do not count toward completion of the project. Violations will be treated severely.
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.
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.

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.

Not conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML