scipy-conference / conf_2014 Goto Github PK
View Code? Open in Web Editor NEWInstantiation of SciPy 2014 materials.
Instantiation of SciPy 2014 materials.
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 :
For us, this means :
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 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.
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.
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.
See the calendar from last year, and set up milestones to track everything.
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.
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:
Community Management:
Working group membership is open to anyone who is interested, and a person can belong to multiple groups.
Group meetings should be:
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.
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.
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.
“Getting consensus” does not mean that every member of the group has to agree enthusiastically, or even agree at all.
What it means:
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.
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.
Write and proof a call for BoF ideas and suggestions.
For communicating where we are all going to.
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.
"""
This is really a meta issue with the following tasks:
Solicit state-of-the-project BoFs like last year.
https://github.com/scipy-conference/scipy-conference/blob/master/mailings/bof_announcement.rst
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.