diff --git a/DevProcess.md b/DevProcess.md
index 9067199..708e345 100644
--- a/DevProcess.md
+++ b/DevProcess.md
@@ -1,44 +1,35 @@
-BOINC development is done by BOINC staff, by the staff of various BOINC-based projects, and by volunteer programmers. Development is divided into several areas. Each area is managed by an 'owner'. 
- 
-|| *Area_'                        || '''Owner'''        || '_Key contributors* ||
-|| API                               || David Anderson     || Bruce Allen, Bernd Machenschalk ||
-|| BOINC Manager                     || Rom Walton         || Charlie Fenton ||
-|| Client                            || David Anderson     || John McLeod, Carl Christensen ||
-|| Mac OS X                          || Charlie Fenton     || ||
-|| Testing and release management    || Rom Walton         || ||
-|| Server                            || David Anderson     || Kevin Reed ||
-|| Translations of GUI and web text  || Rom Walton         || ||
-|| Unix build system                 || Reinhard Prix      || Eric Korpela ||
-|| Web features                      || David Anderson     || Rytis Slatkevicius, Janus Kristensen ||
-|| Windows installer and screensaver || Rom Walton         || ||
+# The BOINC development process
+
+BOINC is free software, distributed under the [Lesser General Public License](http://www.gnu.org/copyleft/lesser.html) (LGPL), version 3 or later.
+
+The University of California holds the copyright on all BOINC source code.
+By submitting contributions to the BOINC code, you irrevocably assign all right, title,
+and interest, including copyright and all copyright rights,
+in such contributions to The Regents of the University of California,
+who may then use the code for any purpose that it desires.
+
+* [The BOINC Github repository](https://github.com/BOINC/boinc/)
+* [Development Workflow](https://github.com/BOINC/boinc-policy/blob/master/Development_Documents/Development_Workflow.md)
+* [boinc_dev](EmailLists), an email list for BOINC developers
+* [Coding style](CodingStyle)
+* [Debugging the client on Windows](DebugClientWin)
 
 
-The BOINC development, testing and release process is shown below. Ovals represent people, rectangles represent information channels. A, B, C, D and E represent the different BOINC development areas. 'Owner A' represents the person who owns area A, as shown above.
+The BOINC development process involves interaction between various groups:
 
-[[Image(//dev_flow.png)]]
+## Participants
+* Report bugs or make feature requests on the BOINC message boards or by creating issues in Github.
 
-# Participants
+## Message board moderators
+* Monitor message boards and forward important posts to boinc_dev or Github issues.
 
-    * Report bugs (or learn of workarounds) on the BOINC message boards.
-    * Learn of new releases on the BOINC web site.
-    * Note: we need ways of 'pushing' info to participants, e.g. via the Manager. 
+## Developers
+* Fix issues.
 
-# Area owners
+## Alpha testers
+* Test development releases and report problems via a Web-based system.
 
-    * Reads the relevant BOINC message board on a regular basis. Decides if new bugs are present. Adds entries to the BOINC/Trac bug database.
-    * Monitors the relevant categories of the BOINC/Trac bug database. Manages entries (delete, merge, prioritize, assign). 
-
-# Developers
-
-    * Are assigned tasks via BOINC/Trac. 
-
-# Alpha testers
-
-    * The [boinc_alpha email list](//email_lists.php) is used to give instructions, and for discussion of tests and procedures.
-    * If bugs are found, log them in BOINC/Trac.
-    * Use web-based interface for submitting test summaries. 
-
-# Release manager
-
-    * Decide when to create test releases; communicate with alpha testers via [email list](//email_lists.php).
-    * Decide when to make public releases, based on web-based reports and on contents of BOINC/Trac. 
+## Release manager
+* Monitor the Alpha-test results and notify area owners of issues.
+* Decide when to create test releases; communicate with alpha testers via [email list](EmailLists).
+* Decide when to make public releases.
diff --git a/JobPrioritization.md b/JobPrioritization.md
index 8226182..e99715d 100644
--- a/JobPrioritization.md
+++ b/JobPrioritization.md
@@ -1,3 +1,5 @@
+# Server job scheduling
+
 This document describes proposed changes to server scheduling policies:
 
 * Feeder enumeration order
@@ -8,7 +10,7 @@ This document describes proposed changes to server scheduling policies:
 These policies work in conjunction with
 [batch scheduling policies](PortalFeatures).
 
-# Quality of service types
+## Quality of service types
 
 We seek to handle the following types of QoS:
 
@@ -19,7 +21,7 @@ We seek to handle the following types of QoS:
    with no a priori deadline.
 * Batches with a short deadline.
 
-# Goals
+## Goals
 
 The goals of the policies include:
 
@@ -27,14 +29,14 @@ The goals of the policies include:
 * Avoid assigning "tight" deadlines unnecessarily, because
   * Doing so may make it impossible to assign tight deadlines
     to jobs that actually need it.
-  * Tight deadlines often force the client to preempt other jobs,
+* Tight deadlines often force the client to preempt other jobs,
     which irritates some volunteers.
 * Avoid long delays between the completion of a job instance
    and its validation.
-   These delays irritate volunteers and increase server disk usage. 
+   These delays irritate volunteers and increase server disk usage.
 * Minimize server configuration.
 
-# Host statistics
+## Host statistics
 
 We need a way to identify hosts that can turn around jobs quickly
 and reliably.
@@ -42,9 +44,9 @@ Notes:
 * This is a property of (host, app version), not host.
 * This is not the same as processor speed.
    A host may have high turnaround time for various reasons:
-  * Large min work buffer size.
-  * Attached to lots of other projects.
-  * Long periods of unavailability or network disconneciton.
+* Large min work buffer size.
+* Attached to lots of other projects.
+* Long periods of unavailability or network disconneciton.
 
 We propose the following.
 For each app A:
@@ -65,7 +67,7 @@ Notes:
    on the assumption that hosts reliable for on version
    will be reliable for the next.
 
-# Batch completion estimation
+## Batch completion estimation
 
 The proposed policies require estimates C(B) of batch completion,
 I'm not sure exactly how to compute these, but
@@ -88,15 +90,15 @@ Notes:
    I.e. if it takes a long time to dispatch the first instances,
    adjust the deadline accordingly to avoid creating a deadline crunch.
 
-# Proposed feeder policy
+## Proposed feeder policy
 
 Proposed enumeration order:
-	
-	(LET(J) asc, nretries desc)
-	
+```
+(LET(J) asc, nretries desc)
+```
 where LET(J) is the logical end time of the job's batch.
 
-# Proposed scheduler policy
+## Proposed scheduler policy
 
 For each processor type T (CPU and GPU) we have a "busy time" BT:
 the time already committed to high-priority jobs.
@@ -109,19 +111,19 @@ For each app A and processor type T, compute the best app version
 BAV(A, T) at the start of handling each request.
 
 The rough policy then is:
-	
-	for each job J in the array, belonging to batch B
-		for each usable app version AV of type T
-			if B is AFAP an there's no estimate yet
-				if P(H, AV) > 50%
-					send J using AV, with deadline BT + R
-			else
-				x = MD(J, T)
-				if x < C(B)
-					send J using AV, with deadline C(B)
-				else if P(H, AV) > 90%
-					send J using AV, with deadline x
-	
+```
+for each job J in the array, belonging to batch B
+	for each usable app version AV of type T
+		if B is AFAP an there's no estimate yet
+			if P(H, AV) > 50%
+				send J using AV, with deadline BT + R
+		else
+			x = MD(J, T)
+			if x < C(B)
+				send J using AV, with deadline C(B)
+			else if P(H, AV) > 90%
+				send J using AV, with deadline x
+```
 
 Make an initial pass through the array
 sending only jobs that have a percentile requirement.
@@ -140,6 +142,6 @@ Notes
    so it doesn't make sense to assign it a score in isolation.
    It's simpler to scan jobs and make a final decision for each one.
    There are a few properties we need to give priority to:
-   * Limited locality scheduling
-   * beta jobs
+* Limited locality scheduling
+* beta jobs
    We can handle these in separate passes, as we're doing now.
diff --git a/PortalFeatures.md b/PortalFeatures.md
index 1df55bb..a641c6e 100644
--- a/PortalFeatures.md
+++ b/PortalFeatures.md
@@ -1,27 +1,27 @@
-[[PageOutline]]
+# Scheduling for multi-user projects
 
-# Computing share
+## Computing share
 
 Demand for a multi-user project's computing power may exceed supply,
 in which case we need a mechanism for dividing the supply among users.
 Assume that every job is associated with a particular user,
 
-and that each such user has a numeric *quota* representing
+and that each such user has a numeric **quota** representing
 the fraction of the computing resource they should get.
 
 What are the precise semantics of quotas?
 Ideally the mechanism should accommodate two classes of scientists:
 
-* *Throughput-oriented*: those who have an infinite stream of jobs,
+* **Throughput-oriented**: those who have an infinite stream of jobs,
    want maximum throughput, and don't care about the turnaround times
    of individual jobs.
-   
-* *Latency-oriented*: those who occasionally have large batches of jobs,
+
+* **Latency-oriented**: those who occasionally have large batches of jobs,
    and who want the entire batch to be finished fast.
    Such a user, for example, might not submit any jobs for a month,
    then submit a batch that takes a day to complete using the entire resource.
 
-## Scheduling batches
+### Scheduling batches
 
 Scheduling batches involves two decisions:
 
@@ -42,7 +42,7 @@ the batch's execution.
 This algorithm can be repeated as jobs complete or time out,
 and as new hosts arrive.
 
-# Prioritizing batches
+## Prioritizing batches
 
 Goals:
 * Give short batches priority over long batches
@@ -65,7 +65,7 @@ LST(U) + R
 
 Priority is given to batches for which LET(B) is least.
 
-## Prioritizing a user's batches
+### Prioritizing a user's batches
 
 With the above design, the batches of a particular user
 are processed in FCFS (possibly with overlap).
@@ -82,7 +82,7 @@ and add R(B)/share(U) to both LST(A) and LET(A).
 In effect, B inherits A's initial global position,
 and A's position is moved back accordingly.
 
-## Notes
+### Notes
 
 The scheme uses a-priori batch size estimates.
 These may be wildly wrong, perhaps intentionally.
@@ -95,7 +95,7 @@ For throughput-oriented users
 the scheme should handle them OK by viewing each
 job as a 1-element batch.
 
-# Combining multiple scheduling types
+## Combining multiple scheduling types
 
 BOINC potentially supports the following types of work,
 each with its own scheduling mechanism:
@@ -116,10 +116,10 @@ in particular, how can we maintain resource shares in their presence?
 One simple approach is to maintain, for each scheduling type T,
 the least LET(T) of any unsent job of type T.
 Then use this top-level policy:
-	
-	for each scheduling type T in order of increasing LET(T)
-		send jobs of type T
-	
+```
+for each scheduling type T in order of increasing LET(T)
+	send jobs of type T
+```
 How to maintain LET(T):
 
 * Job-stream: maintain in the feeder (consider only jobs in the cache)
diff --git a/PrefsRemodel.md b/PrefsRemodel.md
index b92a6f2..d0c2eb6 100644
--- a/PrefsRemodel.md
+++ b/PrefsRemodel.md
@@ -1,4 +1,8 @@
-# Problems with the current system
+# Remodel of computing preferences
+
+**Note: the implementation part of this has been superceded by [this](Prefs2).**
+
+## Problems with the current system
 
 * Too complex: non-technical users see lots of prefs,
    with technical descriptions that many don't understand.
@@ -10,7 +14,7 @@
 
 This document proposes a redesign of the prefs system
 
-# Top-level interface
+## Top-level interface
 
 The top-level interface should consist of four choices:
 
@@ -22,31 +26,31 @@ The top-level interface should consist of four choices:
 The first 3 would be predefined sets of prefs;
 e.g. Energy-saver would compute only when active, and would do CPU throttling.
 
-# Custom prefs
+## Custom prefs
 
 Prefs can be classified as
 
-* *dynamic*: those that might change from one moment to the next,
+* **dynamic**: those that might change from one moment to the next,
  e.g. based on activity or time of day.
  These include:
-  * Do computing?
-  * Do GPU computing?  (and which GPUs to use)
-  * Suspend computing if CPU usage above X
-  * Leave suspended tasks in memory
-  * Use at most X% of processors
-  * CPU throttling
-  * Checkpoint interval
-  * Limit on swap space usage
-  * Limit on RAM usage
-  * Use network?
-  * max download and upload rates
-* *static*: those that don't change
-  * "In use" time interval
-  * Disk prefs (max use GB, max use %, min free GB)
-  * Network connection interval
-  * Additional work parameter
-  * Transfer at most X MB every N days
-  * skip image file verification
+* Do computing?
+* Do GPU computing?  (and which GPUs to use)
+* Suspend computing if CPU usage above X
+* Leave suspended tasks in memory
+* Use at most X% of processors
+* CPU throttling
+* Checkpoint interval
+* Limit on swap space usage
+* Limit on RAM usage
+* Use network?
+* max download and upload rates
+* **static**: those that don't change
+* "In use" time interval
+* Disk prefs (max use GB, max use %, min free GB)
+* Network connection interval
+* Additional work parameter
+* Transfer at most X MB every N days
+* skip image file verification
 
 The following could be either static or dynamic;
 I'd prefer to make them static.
@@ -56,7 +60,7 @@ I'd prefer to make them static.
 * Confirm before connecting to Internet?
 * Disconnect when done?
 
-Let's call a set of dynamic prefs a *configuration*.
+Let's call a set of dynamic prefs a **configuration**.
 The idea is that a preference set consists of
 
 * A single set of static prefs
@@ -71,37 +75,37 @@ which one has precedence?
 My inclination is to allow selection either by in-use
 or time-of-day, but not both.
 
-# Time of day specification
+## Time of day specification
 
 We may as well generalize time-of-day spec
 to allow selection on a per-hour basis, rather than contiguous periods.
 
-# Exclusive Apps
+## Exclusive Apps
 
 We could allow a configuration to go into effect
 when an exclusive app is running
 (rather than simply have processing stop).
 
-# Custom prefs: summary
+## Custom prefs: summary
 
 If the user selects Custom, the editing GUI shows:
 * the static prefs
 * a radio button selection of
   * same prefs all the time
-   * if selected, a single set of dynamic prefs
+    * if selected, a single set of dynamic prefs
   * different prefs depending on time of day/week
-   * if selected, a time-of-day selection interface,
+    * if selected, a time-of-day selection interface,
    and two sets of dynamic prefs
-  * different prefs depending on whether computer is in use
-   * if selected, two sets of dynamic prefs
+* different prefs depending on whether computer is in use
+  * if selected, two sets of dynamic prefs
 
-# Venues
+## Venues
 
 In the web interface, we need to continue supporting venues.
 In addition to Home/Work/School, we should let users specify
 their own venue names.
 
-# Compatibility
+## Compatibility
 
 The prefs schema proposed here is not compatible
 with old-style prefs.
@@ -120,7 +124,7 @@ The best approach I can think of is:
 * the new client can parse both old- and new-style XML.
  If new-style is there, it ignore the old style.
 
-# Possible additions
+## Possible additions
 
 The BOINC client config file (cc_config.xml) has some items
 that maybe should be prefs.
@@ -133,7 +137,7 @@ Dynamic:
 Static:
 * none that I can think of
 
-# Possible deletions
+## Possible deletions
 
 Does anyone actually use the following?
 They could be moved to cc_config.xml
@@ -141,10 +145,32 @@ They could be moved to cc_config.xml
 * "In use" interval (2 minutes should be OK)
 * CPU scheduling period
 * leave apps in memory (should default to No)
-   *This is need for applications that don't have checkpointing. The task would start from the beginning if it is paused and deleted from memory.* There should be a <no_checkpointing/> flag for app_versions and the scheduler should send work only to hosts that allow LAIM.
+   **This is need for applications that don't have checkpointing. The task would start from the beginning if it is paused and deleted from memory.** There should be a \<no_checkpointing/> flag for app_versions and the scheduler should send work only to hosts that allow LAIM.
 * Checkpoint interval
-   *This is used by vboxwrapper to determine how often a checkpoint is set.*
+   **This is used by vboxwrapper to determine how often a checkpoint is set.**
 * Limit on swap space usage
 * network connection interval and work buffer
  (these should by computed automatically based on
- actual behavior)
\ No newline at end of file
+ actual behavior)
+
+## Possible extension to use "Profiles"
+
+Jacob proposed a setup that was akin to using profiles, including an "in-use" profile and an "active application" profile. Then, for each setting, BOINC would use the most-restrictive option across all of the active profiles. The full email is below:
+
+From: Jacob Klein
+To: BOINC Alpha
+Subject: Advanced Settings Feature Requests - Profiles
+Date: Wed, 25 Mar 2015 08:20:19 -0400
+
+BOINC Devs:
+
+I'd like to put in a request for a couple advanced settings features, based on real life scenarios that I encounter daily.
+
+1) When the computer is in use, we should be able to have some new settings. We should be able to give a new "Use at most x% CPUs" setting (so, for instance, now that computer is in use, I only want to use 50% of my CPUs instead of 100%), and also a new settings for "Suspend main GPU only" (so, for instance, now that computer is in use, only do GPU computing on my non-main non-display GPUs, so only 2 of my 3 GPUs), and also a new setting for "Suspend non-CPU-intensive apps when in use." (so that maybe I can configure it to run non-CPU-intensive apps only when computer is in use).
+
+2) When an "exclusive" application is running, we should be able to specify that we want a subset of some of the settings. For instance, we should be able to say "Okay, iRacing.exe is running, so ....  use no more than 50% of the CPUs, and use secondary GPUs only, and use no more than 30% memory, and allow non-CPU-intensive apps." And those should be tied to the exclusive application config in the UI, perhaps renamed to application-specific profiles.
+
+In fact, it's almost like we're making "settings profiles" that are based on:
+- Whether the device is in use
+- Whether a given application is active
+- Using the most-restrictive settings after processing all of the profiles
diff --git a/SoftwareDevelopment.md b/SoftwareDevelopment.md
index 7b677df..3f443c3 100644
--- a/SoftwareDevelopment.md
+++ b/SoftwareDevelopment.md
@@ -1,58 +1,38 @@
-[[PageOutline]]
-BOINC is free software, distributed under the [General Public License](Lesser)(http://www.gnu.org/copyleft/lesser.html)
-(LGPL), version 3 or later.
-The University of California holds the copyright on all BOINC source code.
-By submitting contributions to the BOINC code,
-you irrevocably assign all right, title, and interest, including copyright and all copyright rights,
-in such contributions to The Regents of the University of California,
-who may then use the code for any purpose that it desires.
-
-* [The BOINC development process](DevProcess)
-* [Help wanted - programming](DevProjects)
-* [Quality Assurance Workflow](DevQualityAssurance) (under discussion)
-* [Help wanted - translation](TranslateIntro)
-* [boinc_dev](//email_lists.php), an email list for BOINC developers
-* [Coding style](CodingStyle)
-* [Debugging the client on Windows](DebugClientWin)
-
-# Get and build BOINC software
-* [Get source code](SourceCodeGit)
-* [Software prerequisites](SoftwarePrereqsUnix)
-* [Building on Unix](BuildSystem)
-   * [Installing python-mysqldb](PythonMysql)
-* [Building applications](CompileApp)
-* [Building the client](CompileClient)
-  * [Building the client on Android](AndroidBuildClient)
-  * [Linux VM for building 'compatible' client](VmCompatibility)
-
-# Design docs for current development
-
-* [Simplified attach process](SimpleAttach)
+# BOINC Design Documents
+## Design docs for current development
+* [Reduce use of authenticator](Reduce_usage_of_authenticator)
 * BOINC on Android
   * [GUI discussion](AndroidGuiDiscuss)
   * [GUI development items](AndroidBoincTodo)
   * [Current implementation](AndroidBoincImpl)
   * [Building apps](AndroidBuildApp)
   * [Original planning document](AndroidBoinc)
-* [Unifying Web and GUI Prefs](PrefsUnification)
-
-# Design docs for proposed development
 
+## Design docs for proposed development
+* [Supporting Windows hosts with > 64 cores](WinMulticore)
 * [Generalized credit](CreditGeneralized)
-* [Scheduling for multi-user projects](PortalFeatures)
-* [Job prioritization](JobPrioritization)
 * [Maintaining upload statistics](UploadStatistics)
 * [Locality scheduling redesign](LocalityNew)
 * [Support for OpenID](OpenId)
-* [Remodel of computing prefs ](PrefsRemodel)
+* [Computing preferences version 2](Prefs2)
 * [support for synchronous GPU apps](GpuSync)
-* [rewrite of HTML code using a Web Template Engine](WebTemplateProposal)
 * [Windows Issues](WindowsIssues)
 
-# Implementation notes
-
-## Client: general
+## Design docs for completed development
+* [Work fetch with max concurrent constraints](WorkFetchMaxConcurrent)
+* [Keywords](DesignKeywords)
+* [Simplified attach process](SimpleAttach)
+* [Email Change Notification](EmailChangeNotification)
+* [Delete Account](RightToErasure)
+* [User Opt-in Consent](UserOptInConsent)
+* [Update Password Hashing](PasswordHash)
+* [Unifying Web and GUI Prefs](PrefsUnification)
+* [Manager menu reorganization](ManagerMenus)
+* [Scheduling for multi-user projects](PortalFeatures)
+* [Job prioritization](JobPrioritization)
 
+## Implementation notes
+### Client: general
 * [Client data model](ClientDataModel)
 * [File structure](ClientFiles)
 * [FSM structure](ClientFsm)
@@ -60,37 +40,35 @@ who may then use the code for any purpose that it desires.
 * [Host measurements](HostMeasurement)
 * [Host identification](HostId)
 * [Memory management](MemoryManagement)
-* [GUI notices](wiki:Notifications)
+* [GUI notices](Notifications)
 * [Client app configuration](ClientAppConfig)
 
-## Client: scheduling
+### Client: scheduling
 * [Client scheduling policies](ClientSched)
 
-## Client: packaging
-
-* [Sandbox implementation](//sandbox.php)
-* [Windows installer (V5) ](ClientSetupLogicWin)
+### Client: packaging
+* [Sandbox implementation](https://boinc.berkeley.edu/sandbox_design.php)
+* [Windows installer (V5)](ClientSetupLogicWin)
 * [Client package layout for Unix](UnixClientPackage)
 * [Version 6 Windows installer, design](ClientSetupWinSix)
 * [Version 6 Windows installer, implementation](ClientSetupLogicWinSix)
 * [Unix client packaging](UnixClientPackage)
 * [Spec info for RPMs](RpmSpec)
 
-## Client: screensaver
+### Client: screensaver
 * [Screensaver enhancements](ScreensaverEnhancements)
 
-## Client: Manager
+### Client: Manager
 * [BOINC Manager](ManagerImpl)
 * [Redesign of Choose Project page](ProjectSelect)
 
-## Server: general
-
+### Server: general
 * [Job size matching](JobSizeMatching)
 * [Multi-user project features](MultiUser)
 * [APIs for remote job submission](RemoteJobs)
 * [Homogeneous app version](HomogeneousAppVersion)
 * [job runtime estimation](RuntimeEstimation)
-* [Credit system as of 5/2010 ](CreditNew)
+* [Credit system as of 5/2010](CreditNew)
 * [The BOINC database](DataBase)
 * [Backend state transitions](BackendState)
 * [The logic of backend programs](BackendLogic)
@@ -101,40 +79,36 @@ who may then use the code for any purpose that it desires.
 * [Adaptive replication](AdaptiveReplication)
 * [Low-level validator framework](ValidationLowLevel)
 
-
-## Server: scheduler
+### Server: scheduler
 * [Scheduler job matchmaking](SchedMatch)
 
-## Server: Packaging
-
+### Server: Packaging
 * [Unix project packaging](UnixProjectPackage)
 
-## PHP code (web pages and RPCs)
+### PHP code (web pages and RPCs)
 * [PHP database abstraction layer](PhpDb)
 * [Style Sheets](StyleSheets)
 
-## Protocols
-
+### Protocols
 * [Protocol overview](CommIntro)
 * [The scheduling server protocol](RpcProtocol)
 * [Scheduling server timing and retry policies](RpcPolicy)
 * [Data server protocol](FileUpload)
-* [Persistent file transfers ](PersFileXfer)
+* [Persistent file transfers](PersFileXfer)
 * [XML notes](XmlNotes)
 
-## Simulation
-* [BOINC Client Emulator](The)(http://boinc.berkeley.edu/dev/sim_web.php)
-* [BOINC server emulator](EmBoinc)(http://gcl.cis.udel.edu/projects/emboinc/index.php)
+### Simulation
+* [The BOINC Client Emulator](https://boinc.berkeley.edu/dev/sim_web.php)
+* [EmBoinc BOINC server emulator](http://gcl.cis.udel.edu/projects/emboinc/index.php)
 
-## Source code documentation (in progress)
-* [API](//doxygen/api/html/index.html)
-* [Client](//doxygen/client/html/index.html)
-* [Manager](//doxygen/manager/html/index.html)
-* [Server components](//doxygen/server/html/index.html)
-* [PHP code](//doxygen/web/html/index.html)
-
-## Miscellaneous
+### Source code documentation (in progress)
+* [API](https://boinc.berkeley.edu/doxygen/api/html/index.html)
+* [Client](https://boinc.berkeley.edu/doxygen/client/html/index.html)
+* [Manager](https://boinc.berkeley.edu/doxygen/manager/html/index.html)
+* [Server components](https://boinc.berkeley.edu/doxygen/server/html/index.html)
+* [PHP code](https://boinc.berkeley.edu/doxygen/web/html/index.html)
 
+### Miscellaneous
 * [Volunteer data archival](VolunteerDataArchival)
 * [BOINC/Condor integration](CondorBoinc)
 * [Low latency computing](LowLatency)
@@ -143,18 +117,20 @@ who may then use the code for any purpose that it desires.
 * [Python-based simplified app development](PythonAppDev)
 * [Python master/worker system](PythonMw)
 * [Cross-project user identification](CrossProjectUserId)
-* [Simulator of a project using locality scheduling](//loc_sim/)
+* [Simulator of a project using locality scheduling](https://boinc.berkeley.edu/loc_sim/)
 * [Preferences](PrefsImpl)
 * [Trickle messages](TrickleImpl)
 * [How to see what has changed between two versions of an executable](VersionDiff)
 * [XML formats](XmlFormat)
 * [Diagnostics API](DiagnosticsApi)
-* [Simple Account Creation](Proposal/ProjectSimpleAccountCreation)
-* [BOINC on Phones](wiki:BOINConPhones)
+* [Simple Account Creation](Proposal_ProjectSimpleAccountCreation)
+* [BOINC on Phones](BOINConPhones)
 
-# Historical
+## Historical
 Design docs for old versions, or for ideas that never happened.
 
+* [rewrite of HTML code using a Web Template Engine](WebTemplateProposal)
+* [Remodel of computing prefs](PrefsRemodel)
 * [Virtual machine apps (deprecated)](VmApps)
 * [Old client scheduling policies](ClientSchedOld)
 * [Client scheduling changes](ClientSchedOctTen)
@@ -163,12 +139,10 @@ Design docs for old versions, or for ideas that never happened.
 * [Automatic update](AutoUpdate)
 * [Automated estimation of job characteristics](AutoFlops)
 * [Python testing framework](PythonFramework)
-* [Version 4 runtime system](//api_v4.php)
-* [Mac/Intel plan](//mac_intel.php)
-* [Old Mac project plan](//mac_devgroup.php)
-* [Design of version 5 setup](//new_setup.php)
-* [Mac Menubar](//menubar.php)
-* [Usability discussion](//suggestions.php)
+* [Version 4 runtime system](https://boinc.berkeley.edu/api_v4.php)
+* [Mac/Intel plan](https://boinc.berkeley.edu/mac_intel.php)
+* [Old Mac project plan](https://boinc.berkeley.edu/mac_devgroup.php)
+* [Design of version 5 setup](https://boinc.berkeley.edu/new_setup.php)
+* [Mac Menubar](https://boinc.berkeley.edu/menubar.php)
+* [Usability discussion](https://boinc.berkeley.edu/suggestions.php)
 * [Screensaver logic](ScreensaverLogic)
-
-