New England Programming Languages and Systems Symposium Series (NEPLS): Manifesto

NEPLS should strive to follow and foster the following tenets:

Research is often a social activity, and NEPLS is a watering hole for researchers. Hosts should try to enhance the potential for social interaction, picking venues and schedules accordingly.
The event is largely non-competitive. There will usually be only a few more requests to speak than available slots. Speakers should therefore temper their talks to a broad audience, rather than try to dazzle their colleagues as they might be tempted to at, say, a conference.
While NEPLS does offer its attendees a venue to hear about the best and brightest recent work, it also affords more incipient work a chance to garner some public review and, hopefully, useful recommendations. It also gives students an opportunity to observe projects at intermediate points in their trajectory, and to seek counsel on their own work in a more nurturing environment than the typical conference.
Because attendees represent great diversity within the PLS field, NEPLS both needs and should solicit tutorial talks. In contrast to conferences, which are (largely) unwilling to accept tutorial papers, recognition at NEPLS should serve as an incentive to construct tutorials.

NEPLS should try to meet three times a year: once each in the spring, summer and fall.
A month into each period seems to be a good time to meet. This dodges the academic hiring season, the peak vacation period, the worst of winter weather, and most final exams.
NEPLS should try to avoid meeting soon before or after meetings of NJPLS (which seems to have a roving home) and the Programming Languages Day at IBM Watson. It should also take conference deadlines into account.

NEPLS should strive to be ``regional''. This means events shouldn't be clustered in one city or region. A tentative ``regionality'' test is that at least one event each year should be in a venue not easily reachable from the coastal Amtrak lines.
NEPLS should also recognize that Boston has a preponderance of researchers in this field. This may mean that one meeting each year convenes in Boston.

Each meeting will have a three-member speaker selection committee, consisting of the former, current and next hosts.
The host will try to ensure that the committee represents a mix of both ``theory'' and ``systems''. The term systems should be construed to mean people who either implement and distribute software or analyze the performance of computer systems, so long as there's a significant linguistic angle: typically, compiler writers, environment builders, or garbage collection analysts.
Speakers will petition for a slot length. Slots can be between 15 and 60 minutes long (including discussion). The committee may grant a different slot length than requested — either longer, because they believe the topic needs more preliminary exposition, or shorter, because they feel the contribution is smaller than advertised. The committee should remind speakers given a longer slot to use the extra time for a tutorial, not to cram in additional research results.

The event should meet from about 10am to about 4pm. It should start late enough and end early enough to allow people who need to travel about three hours to attend.
The host venue does not need to provide lunch, though in this case they should have information handy on where attendees can find lunch, hopefully nearby. Hosts should account for dietary preferences such as kosher, abstinence from pork, and vegetarianism.
Events should have several breaks; ideally, there should be no more than two talks in a row. Breaks double up as buffer time to guard against sessions that overflow their allocated time.
Hosts should try to organize tool demos, and encourage tool writers to demonstrate their work-in-progress.