Solicit state-of-the-project BoFs like last year.

https://github.com/scipy-conference/scipy-conference/blob/master/mailings/bof_announcement.rst

I find persistent chatrooms useful for collaboration. They don't interrupt in the same way an IM does, yet also allow for IM-style conversations if people are around.

This can be useful, for example, if I'm working on the website with someone and we have some quick question. That type of interaction has worked well for me in the past.

Not everyone has the same communication style so I'll set this up, and if people use it, I'll be happy, but if people don't, I'll adapt to the preferred communication style.

Before you make the announcement about the call for abstracts and papers, you need to define the requirements for the submission format for the abstracts.

Additionally, it is usually also good to be ready at the same time with information about the format and submission process for the papers that will eventually go in the proceedings.

Last year the abstracts had the following requirements :

"""
The 150-300 word abstract should concisely describe software of interest to the SciPy community, tools or techniques for more effective computing, or how scientific Python was applied to solve a research problem. A traditional background/motivation, methods, results, and conclusion structure is encouraged but not required. Links to project websites, source code repositories, figures, full papers, and evidence of public speaking ability are encouraged.

Each abstract will be peer-reviewed by multiple members of the Program Committee Board. Please submit your abstract at the SciPy 2013 website [2] abstract submission form. Abstracts will be accepted for posters or presentations.
"""

The first task as program committee chairs is the assembly of the rest of the program committee. This consists of two groups, the mini-symposium chairs and the abstract reviewers.

• Determine mini-symposium themes
• Invite mini-symposium chairs
• Invite reviewers for abstracts (and papers)

From the program committee manual :

Mini-symposium chairs should be recruited as soon as possible. The mini-symposium address scientific python in a domain-specific sub-community. It is the mini-symposium chair's role to encourage participation from their community, select talks for the session, and organize the content of the session. The content and organization of the session is left up to the discretion of the mini-symposium chair. In the past, they have consisted of a series of talks, panel discussion, "state of the community", or a combination of the above. Since a large amount of growth of the conference comes from the recruitment in these sub-domains, it is important to get the mini-symposium chair engaged early on.

The duties of reviewers on the program committee are not as extensive as the mini-symposium chairs, but they are very important. A large number of reviewers are required to address the increasing number of submissions. The number of reviewers to be recruited can be computed as:

r = s * 3 / (10  * (1 - a))

where r is the number of people to recruit as reviewers, s is the expected number of submissions, and a is the expected attrition rate. Each submission should have three reviews, and ten reviews is a reasonable expectation from a reviewer. The attrition rate depends on the set of reviewers -- it is approximately 0.3.

For communicating where we are all going to.

I'm pasting in some text based on the OSC blog's decision making process. I helped review it for the group. I'll replace text about the OSC blog or just leave it blank.

Group Structure

Within the SciPy conference, there are several domains of responsibility or “working groups”:

(note: I'll just list a few here, there were more for the OSC blog)

Technical:

• conference site development/maintenance/training
• proceedings platform development/maintenance/training

Community Management:

• inviting new team members
• dealing with conflict resolution between members
• oss support/outreach

Membership

Working group membership is open to anyone who is interested, and a person can belong to multiple groups.

Documentation of workflow

Group meetings should be:

• recorded: either directly, by being held in a text-based medium such as IRC or gchat, or by assigning someone at the meeting to take notes
• planned: it’s recommended that an agenda be created and shared before the meeting, and that decisions and action items be created and shared during/after the meeting
• open: when choosing how to meet, be mindful to use non-proprietary tools so anyone can join

Work style, leadership, and decision-making

As an open project, the most critical features of work style, leadership, and
decision-making are open communication and respect for all contributors. How
decision-making actually occurs can vary widely as long as the values of
openness and respect are embodied in the process. While the default process is
that which is established by the entire OSC blog group (see below), groups
should feel free to determine their own system, organization of leadership,
and/or division of roles and responsibilities. They should make sure all group
members find the chosen process acceptable, and it is recommended that they
check in occasionally with members to make sure it remains so.

Conflict management

If their process fails to solve a problem, and help from a community manager/disinterested party doesn’t help, they can put the process before the full “oscblog” group, either informally or through the formal consensus-based process defined below.

Decision-making process:

It’s important to us that individuals have the freedom to make decisions about
their work and to use their own time efficiently. Therefore the default
decision-making process is “do-ocracy” - if you’re willing to make the effort
to do something, do it! If it’s a decision that affects other people, it’s
requested that you look for informal agreement among working groups or the
SciPy organizers as a whole. Informal agreement typically means sending an
email and waiting 12-24 hours to see if anyone objects.

Occasionally, however, there will be major decisions that need to be made,
disagreements over how to proceed or conflict between individuals. To deal
with these circumstances, we’ve defined a consensus-based resolution process.
Anyone may request that a more formal process take place, however practically
speaking we do not expect this to be very common.

Formal Consensus-based Process:

“Getting consensus” does not mean that every member of the group has to agree enthusiastically, or even agree at all.

What it means:

1. Anyone who cares about the decision has had the option of being part of the
   consensus process. (Anyone who doesn’t care can abstain!)
2. “Being part of the consensus process” means that everyone participating who
   wants to make their opinion heard can do so. Ideally discussion focuses on
   clarifying disagreement and seeking compromise. The outcome of a consensus
   discussion is a proposal (often this is the initial proposal that began the
   discussion, but is also frequently a modified or alternative proposal). The
   group should aim to make sure discussion is finished before bringing the
   proposal to a vote.
3. Participants are asked to vote for or against, abstain, or block the
   proposal. Some threshold/percentage of for vs against votes, pre-determined by
   the group, ensures the proposal’s passage.
   • “Voting for” - participants want the proposal to pass and be enacted
   • “Abstain” - participants do not care enough about the proposal to vote either way
   • “Voting against” - participants do not want the proposal to pass but will accept the outcome
   • “Block” - participants are very strongly against the proposal. Blocking
     should only be done on issues where the blocker is willing to leave the
     group over the disagreement.
4. When a proposal is blocked, a second round of consensus-seeking occurs, with
   the goal of formulating a new proposal that addresses the blocker’s objections.
   Members of the group who had not been participating may be made aware of the
   seriousness of the disagreement. After discussion, another vote happens.
   (Groups may require that a greater % of votes must be positive when someone is
   blocking.) If the proposal passes, it is enacted, and it is up to the blocker
   whether to remain as part of the group.

The landing page conferences.scipy.org needs to be more than it is.

@pv recommends putting it on scipy.org,

@aterrel thinks perhaps a place for all the scipy community to blog (such as a simple pelican site).

See the calendar from last year, and set up milestones to track everything.

Write and proof a call for BoF ideas and suggestions.

This is really a meta issue with the following tasks:

• Set up a MailChimp account.
• Get current list from Enthought.
• Update scipy2014 webpage
• Start sending announcements from mailchimp
• MailChimp settings
  • verify from domain

The deadline dates should be sufficiently late to allow authors time to submit relevant, quality abstracts. They should, however, be sufficiently early so that there is time for reviewers to submit their reviews and for the chairs to arrange the final schedule significantly before the registration deadline.

Let's work backwards :

• At least two months should be allowed before the conference starts to when the speaker and poster schedule is announced. The schedule attracts people to the conference and allows attendees to plan their attendance.
• Approximately two weeks before the schedule announcements, the deadline for reviews should be planned to allow the PC chairs time to create the schedule.
• Approximately three weeks prior, the abstracts should be distributed to reviewers to give them sufficient time to review.
• Two weeks prior, the deadline for abstracts submissions should be place. This allows a week for a deadline extension and a week to sort abstracts to distribute to reviewers.
• Approximately three months prior, the call for conference abstracts should be made to give submitters sufficient time to prepare their abstract.

For us, this means :

• July 6 - two months = May 6 <- announce talk schedule
• May 6 - two weeks = April 21 <- reviewer deadline
• April 21 - three weeks = April 1 <- distribute abstracts to reviewers
• April 1 - one week = March 21 <- extended abstract deadline
• March 21 - one week = March 14 <- Initially announced abstract deadline?

In relation to the "Full Paper Deadline" we also need to pick a deadline that will allow reviewers sufficient time to review the papers before the proceedings are published. The determination of this date must be discussed with the proceedings chairs, but I recommend one month before the conference.

The main themes will direct the primary direction of two of the three main tracks of the conference. The third track is the "general" track.

The mini-symposia address scientific python in a domain-specific sub-community. We need to select a number of them. The number of mini-symposium themes selected will depend on the room for mini-symposia on the schedule. Last year there were 5.

It is the mini-symposium chair's role to encourage participation from their community, select talks for the session, and organize the content of the session. The content and organization of the session is left up to the discretion of the mini-symposium chair. In the past, they have consisted of a series of talks, panel discussion, "state of the community", or a combination of the above. A large amount of growth of the conference comes from the recruitment in these sub-domains.