Portal Polling Process
This page describes portal polling functionality being developed according to the Portal Process Process.
The foundation board has asked that committers be regularly surveyed and that survey results be reported as a key processs indicator (KPI) on a quarterly bases.
One survey was conducted by FOSS researchers from Norway. Although we discussed having them share results and possibly do further surveys, we have only ever conducted one survey and recieved its preliminary results.
Bjorn predicted that response rate for the Norwegian survey would be about 10%, which it was. Ward suggested that response rate be used as a question independent metric to be tracked quarter to quarter as a KPI.
With the advent of the MyFoundation portal, we have the opportunity to present poll questions on a regular basis. We suggest that an average polling rate of one question a week will give highest response rate and finer temporal resolution than traditional web polling methods.
We also believe that interesting questions and immediate tallys will encourage regular visits to the portal which will have indirect benefits associated with higher levels of participation.
find and answer poll
- a committer will be presented with a new poll question each week
- he/she makes one selection. on a five step scale of disagree to agree, and submits choice.
- choice view is replaced with instant results as bar graph
- bar graph updates (with each refresh) as others complete the week's poll
- a committer can add an open ended comment in addition to five step scale.
- a committer can edit a previously cast choice or comment throughout the week.
- if there are no current poll questions, no component appears
read comments from others
- a committer has cast a choice and sees bar graph
- he/she indicates one bar of the graph to see comments associated with that bar
- (we suggest this use the bubble mechanism of swim.php)
- if there are no comments, an indication of this replaces comments display
- if there are too many comments to view, some are selected by an arbitrary means
suggesting new questions for polls
- a committer chooses to suggest a question
- he/she is presented with a list of pending questions
- he/she can check off any pending questions and endorse them
- he/she can add a new question and endorse it instead
- apply same text conversion as committer vote (recognizing urls and bug numbers)
pollmeister selects questions for poll
- the default behavior is that the most endorsed question is automatically selected each week
- someone with extra privilage, the pollmeister, sees a suggest view with more options
- he/she selects one or more questions and presses post
- the questions are scheduled to the next available weeks
- the view returns to an updated suggest view that has scheduled questions annotated with post date
- a similar option allows the pollmeister to delete questions, scheduled or otherwise
- a question can be unscheduled by deleting it and resuggeting it (it will also loose all endorsement)
Polls will consist of a single component, instantiated for committers, and customized for pollmeisters.
The component will offer three views, revert, choose, and suggest.
Revert will be the default view when a choice has been cast, choose will be the default view otherwise.
Revert will offer links [choose] and [suggest] to other views. They will provide link [rever] back to revert. Choose will only provide the [revert] link when a choice has been made. This behavior mirrors that of voting in New Committer Process.
The component will have DailyActivity that ensures that we have a new question posted every week. It will use logic such as the following.
- do we have a question posted for next week
- if not, do we have a question in the queue
- if so, post the most endorsed question for next week
Polls will be stored as two new portal tables.
- id -- unique, automatically generated
- statement -- text -- something to which committers can agree or disagree
- submit -- date -- creation date of entry
- post -- date -- first day of 7 day posting period (past or future)
- question -- id of Poll_Question
- user -- login id
- endorsement -- boolean -- has this user endorsed this question
- agreement -- integer or null -- has this user cast a choice, and if so, what choice
- comment -- text or null -- has this user offered a comment, and if so, what comment
Development will take place in phases, each lasting a day or two and employing one or two people.
- phase 1
- make db tables -- done
- make revert view reporting decimal numbers -- done
- make report with cool graphics replacing numbers -- done
- check that factory works without questions -- done
- make choose view -- done
- no default choice, but choosing is required -- done
- check that repeated choosing is ok -- done
- phase 2
- make suggest view -- done
- show existing suggested questions -- done
- accept endorsement of questions -- done
- show user's current endorsements as initial checks -- done
- retract endorsement when save with checks cleared (postponed)
- warn buildmeister that checks mean multiple things -- done
- check that view works with no suggestions -- done
- accept new suggestion entry -- done
- add delete function available to pollmeister -- done
- add post function available to pollmeister -- done
- make the DailyActivity -- done
- make suggest view -- done
- phase 3
- make bubble thing to show comments on revert view -- done
- write dash page for accessing poll history -- writen as pollmeister action
- master page shows table of question, date, and numeric tally -- done
- details page shows choice and comment for a specific question -- deferred until dash can access db
- make the component delayed loaded (is_slow) as a performance enhancement -- judged bad idea
- make factory instantiate component without query -- judged bad idea
- make suggest view the default view if there are no questions -- delayed until community is familiar with suggesting
The choices of each committer are recored in the portal database keyed by their login. We will not provide means for identifying the source of any questions or answers, but will acknowledge that anyone with privilaged access to the database could gain this information. We will not employ any technical means such as encription to prevent access.
There are no security concerns not already attended to by the components of the New Committer Process which have already been addressed.
We will consider the component useable if we achieve a 10% or greater response rate. We will initially measure this as poll choices cast vs. committer votes cast until we establish some better measure of committer portal usage. A one-time committer emailing will offer another opportunity to measure response rate (see below).
Beta deployment is possible after phase 1, if questions are loaded by ad-hoc query. We recommend beta deployment after phase 2 and full deployment after phase 3.
We will launch with two months of questions. The pollmeister will use repeating calender events to remind him or her to check monthly that there are sufficent questions. The pollmeister will also report to the board quarterly participation numbers.
After a month or so of experience we will email all committers suggesting participation on a week with a suitably good suggestion.
We will launch with four questions, enough for one month operation. Questions are in the form of a statement that can be agreed with or disagreed with. Each question should stand alone and be of reasonable interest and substance.
1. Our users would rather interact with us using web based forum software than the news software that we now require.
2. When a committer intends to stop participating for many months, they should tell the community that this is so and possibly offer an explaination.
3. It is important that the Eclipse developer has a pure open source tool chain even if it means forgoing tools like Jazz.
4. The Foundation should recreate the project dashboard that ranked projects by activity.