Things we're working on, will release soon
- Simple GUI, prefs dialog
- CPU throttle
Things we could consider doing
Client GUI/core client/installer
- Add an 'advanced prefs' dialog that includes all prefs,
with two save buttons:
'save to web (affects all hosts)'
and 'save locally (affects this host only)'.
- 'Attach to project' wizard shows list of popular projects,
with the ability to type in URL of other project.
List of projects is obtained dynamically from boinc.berkeley.edu.
(recent list also included in a file).
Also, remember what projects the client has been attached
to (but is no longer) and add them to the list.
- Attach-to-project wizard
prepopulates email/password fields for 2nd and subsequent attaches.
- Control resource shares in Manager.
- Make BOINC easier to use with command-line interface (boinc_cmd).
- Make Linux install easier.
[ Several distributions (Gentoo/portage, debian/ubuntu, redhat/fedora)
seem to have done this already.
Need to research these, give appropriate instructions on BOINC web site. ]
- Increase time resolution of CPU throttling
so Task Manager doesn't see on/off changes.
- A scheme where projects could offer a 'join' link,
which would either work directly (via href=boinc:projecturl)
or by downloading and opening a file (named projecturl.boinc).
See emails from Goldsmith and Alvarez about how to do this.
'Asynchronous pluggable protocols': see
- Have BOINC sense CPU temperature.
Control fan speed and/or do CPU throttling accordingly.
Comments: 8) is probably impractical; it would be a huge development effort.
The other ideas are do-able, and I like them.
Comments: all should be doable.
- Tolerate slow computers better,
i.e. those that take a month to finish a SETI@home WU.
Maybe change the scheduler so that it sends results of a WU
to similar-speed computers,
and chooses an appropriate deadline for them.
- Add counters to user/hosts records for
total results, total success results.
(for people who like to count workunits, not credit).
- Don't compute credit based on core client benchmarks.
Use some other mechanism, e.g. reference WU.
Possible new support channels:
Possible changes to existing mechanisms:
- Use a 'Trouble Ticket System' (TTS).
For an explanation of what this is, see
Create a 'volunteer support group' (VSG) to handle tickets.
(Anthony Strong suggested some S@h users).
(Tigher: moderator != support volunteer).
Create queues so that VSG can pass things on to developers if needed.
Make the answers searchable?
Use email lists for support.
2nd level email list for discussion among VSG.
Volunteers can forward questions to 3rd level (project admins).
Project admins can forward questions to boinc_dev.
Possibly make Q&A forums posts feed into the email list.
- Add a 'chat with a support volunteer' button,
either text-based (Skype or IRC)
or VOIP (Skype or other).
Nicolas: could build IRC support into Manager.
- Resurrect the BOINC forum's Q&A mechanism
(which was lost in Janus' rewrite a few months back).
This old mechanism questions in order of how frequently they've been asked,
rather than chronologically.
It shows answers in order of how highly they're rated.
The goal is to make the Q&A into a user-editable FAQ,
rather than a message board.
- Wiki-based FAQ
- 'Over your shoulder' video showing download/install/attach.
(Tony): have an 'ask tech support' button on the GUI
(possibly on the project-specific panel) which goes to a compose-email page
(possibly with menus for OS, BOINC version).
- Project sites have a FAQ page for top 10 problems/misunderstandings.
- Moderate the Q&A boards
Questions (from David):
(JM7) It would be nice to have support questions and answers posted somewhere,
searchable, to minimize new questions.
Tony: users shouldn't be expected to scan existing questions;
a personal response is very important to them.
Customer support potentially as two stages:
Do we need both of these?
Should they have separate mechanisms?
Can one mechanism do both?
- a place where the user finds an existing answer to their question
(i.e. an FAQ or web page);
- a place where they can ask questions.
Is it desirable to screen support volunteers?
Is it important to have each question 'owned' by one volunteer?
Should each project have its own customer support system?
Should customer support be centralized?
Somewhere in between?
Can we expect users to know whether their question is project-specific?
Return to BOINC main page
Last modified 8:52 PM UTC, October 17 2012.
Copyright © 2017 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the
GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.