Fork me on GitHub
Math for the people, by the people.

User login

Asteroid Bulletin (New Series) for Monday, October 5, 2009

Primary tabs

Asteroid Bulletin (New Series) for Monday, October 5, 2009


This bulletin has notes on our recent Third Quarter board
meeting (see below), and a summary of the state of our new
tag- and role-based content management system (up next!).

Joe Corneli,


This week I've been helping facilitate a discussion
between the board, the content committee, and the
programming team about tags and roles. The basic system
exists in the dev server and just needs to be fine-tuned
for our purposes.

Here is the set of tags that reflect the group's current
consensus (as I understand it). This should convey the
basic idea of our new workflow design, too.



Every new article should start out with one of these two

- NS:Open (anyone can see it when given a direct URL)
- NS:Closed (content is only accessible to Coauthors or
perhaps "Approved Viewers"?)

(Authors can choose to move items between NS:Open and
NS:Closed at will.)


Whenever the Author thinks it is ready, it will be
submitted for review, and it will acquire the following
tag instead of its original tag. ("Approved Authors" can
bypass this step and go directly from Step 1 to Step 3)

- NS:Submitted (Publication requested)

NS:Closed articles that are "submitted" should turn into
NS:Open articles (after a warning).


Case 1. If the Editors agree that the article is
publication-worthy, the NS:Submitted tag is deleted, and
one of these tags is added:

- NS:Encyclopedia (Like what we have now.)
- NS:Recreational (Fun stuff.)
- NS:Research (New stuff.)

(The NS:Open tag is retained by all of these articles for
a good reason I'll mention in the notes.)

Case 2. If the article is not deemed publication-worthy,
it does not get any of these "special collection tags",
and is moved out of NS:Submitted (or, after due deliberation,
out of whatever Published category it happens to reside in)
into NS:Open, but it is also given an NS:Returned tag. The
NS:Returned tag will be removed if the article is resubmitted
and approved for publication.

(Articles in one of the "special collections" can be
"returned" as well; they lose the special collection tag
and get tagged as NS:Returned, NS:Open.)


These tags do not have a direct bearing on "standard
workflow", but rather, are intended to provide refined
categorizations that help make our resources more useful
to downstream users.

The intention is that tags should be viewable by category
and by intersections and unions of categories.

"Edlevel" tags are presented here in hierarchies, so that
e.g. "edlevel:elementary" implies "edlevel:school", but
"edlevel:basic" and "edlevel:undergraduate" are mutually
exclusive. Tags in the other dimensions are supposed
to be mutually exclusive.

Tentative plan: The tags for categorization can be changed
by Authors or Editors. (Or should we just have them be
controlled by Editors?)


* edlevel:school
** edlevel:elementary (elementary school, 1-4 grades)
** edlevel:middle (middle school, 5-8 grades)
** edlevel:high (high school, 9-12 grades)

* edlevel:undergraduate
** edlevel:freshman (introductory undergraduate)
** edlevel:major (advanced undergraduate)

* edlevel:graduate (including postgraduate)
** edlevel:master (beginning graduate, before preliminary exams)
** edlevel:doctorate (advanced graduate)


* explevel:popular (Simplified, impressionistic treatment of a topic)

* explevel:introductory (Exposition which assumes no prior knowledge)

* expltevel:intermediate (Assumes some prerequisites)

* explevel:advanced (Assumes familiarity & mathematical maturity)

* explevel:specialist (No simplifying assumptions)


* audience:student (E.g. explanation of how to solve some
textbook problems.)

* audience:teacher (E.g. suggestions on how to explain and
illustrate a certain concept in the classroom.)

* audience:autodidact (E.g. a self-paced tutorial on some

* audience:researcher (E.g. survey of work done and open
problems in an area.)


* area:pure (Entries discussing math for math's sake.)

* area:applied (Using math to understand phenomena outside of math.)

* area:cultural (About the social, cultural, and historical context of math.)

* area:interdisciplinary (About subjects in between mathematics and
other disciplines.)


* type:minimal (The entry simply states a fact.)

* type:maximal (The entry gives a complete treatment of the subject.)


High-level summary:

We talked a lot about code and documentation, and how to
manage the project so that things go more smoothly. If
the Admin dives in to the documentation process as
planned, that will help. We further need to understand
some details of the Programmer's contractual arrangements
and be clear about terms and conditions.


* How much time does James have to put in?

* Can we look at James's contracts? How does his funding
work? Number of hours per week, deliverables?

* Do we (as PM) have a contract with Springer or anyone

* Can we get a date to roll things over to the new server?


A lot of content stuff is waiting until we get the new
code going.

We'd like to have the new server up in a month, with
whatever features are ready at that time (even if it's
just the existing codebase). To extent that the
programming work is "modular" we should be able to add new
features in module by module.


Ongoing evaluation: James needs to document stuff, and to
whatever extent seems workable, payment should be
contingent on both documentation and delivery. Whatever
James's responsibilities to Pitman and Springer are, we
also need some clear conditions for James vis a vis work
with PM.

Ongoing management: We need to get the programming stuff
tied into the reality of dates, deliverables, money.
(Right now, that translates into understanding "what is
James planning to do, and when", but the considerations
should become broader once we understand that part.)


We some money in the bank ($8000?) so we could hire an
additional programmer, someone who could work on things
that James might not have time for and/or things that are
not part of his job description. E.g. things we currently
bug Aaron for (like auto-generated snapshots).

Eventually all the little add-ons like that, or like the
email bridge, should be worked into the main distribution.
And the "distribution" should be documented so we know
what's in it.

If we document starting with the *features* we want, we
can then make good decisions about how we're going to
implement these features. For example, what things would
third party software be useful for?

Furthermore, if we document things based on
*functionality*, we'll at least have an idea of what we
have "working" and what we don't. It would be good to
have specs for each feature, so when we test new work,
we'll know whether the code meets the spec.


To come up with a Master Plan or Project Plan: as for
moving forward with the code, to begin we could take the
Feature Requests (from us, or Springer or Pitman), and
prioritize them. We can make some estimates, and also ask
James to give his views, as to how much time they will

For Joe as Admin, working on the various aspects of
documentation is now a priority. That will begin with the
"new features" investigation THIS WEEK.

Within a month or two we could have an actual "management
plan" that integrates old feature requests, old bounties,
old bugs, old user docs and code docs, and organizes

We need to devise a procedure whereby the Feature Requests
get plugged into actual development work

We'll swap links that we know would help with this
planning/documenting process.

(A weekly reminder!

President's tasks

* Make sure snapshots are being made right.
* Supervise various programming tasks (below); coordinate with
participating organizations. [ONGOING]

Programmer's tasks

* implement new template system (coordinating with Pitman, Springer) [ONGOING]
* provide support for testing of editorial/content committee features

Admin's tasks

* Assist with the next board meeting — remind people of the date,
manage the agenda and circulate it to the board, take minutes and file
them away where appropriate.
* Co-author documentation of PM organization.
* Lead revision of our survey of metacommons-related projects in math
and find a suitable venue for publication as part of our PR strategy
(see Surveying the Math Metacommons).
* Maintain this tasklist and an overall organizational roadmap (the
latter at PlanetMath Admin). Assist other members of the organization
in creating their own roadmaps.
* Figure out what's going on with the "email integration" feature that
was developed some time ago.

Board tasks

* Schedule the next board meeting.
* Look for funding sources.

R.S.P.'s tasks

* Co-author documentation of PM organization.

Subscribe to Comments for "Asteroid Bulletin (New Series) for Monday, October 5, 2009"