Sage Usability Tasks

Source: Sage Usability Improvements List. TODO: Assign difficulties to individual tasks, if it's appropriate, or just order or group by difficulty.

1. General

2. Documentation

3. Development

On Thu, Sep 24, 2009 at 11:07 AM, Robert Bradshaw wrote:

Here's my ideal system (which rietveld may or may not be a part of,
but certainly it'd be better to not start something from scratch).

0) I hack on my own code, committing as I want, the normal mercurial
way.
(1) I run a sage command that takes all my changes and uploads them
to trac (or rietveld, or Review Board, or ...). It may or may not
flatten them. The ticket description should be no more than the
commit description (i.e. our commit descriptions should be a lot more
verbose.)
(2) This patch automatically gets applied to the current alpha, any
merge problems, build problems (including documentation), or test
failures get reported and bounced back. Linting could happen at this
point too (everything from no tabs to coverage to "Sage:" in docstrings)
(3) Upon a successful build (or even not) this build gets saved and
can be accessed and played with (via the notebook or by ssh-ing into
a virtual machine). The code can be browsed and commented on.
(4) Reviewer makes comments, as a whole or line-by-line. They can use
(3), browse the code, and have a sage command like sage -merge that
will quickly update their local copy to the state of the ticket, and
allow them to push as well.
(5) I can quickly address those comments via a sage -b into that
branch (or otherwise using queues/etc. to get back to my ticket
state), make my changes, and re-push to trac. Building and tests
happen after every push. This point here is not to be underestimated--
I think it will greatly improve the quality of the code to lower the
overhead of the feedback loop.
(6) When the reviewer is happy, he marks it as positive review.
(7) The release manager(s) approve the patch. At this point they know
it builds, passes tests, and has at least one positive review. It
goes into a queue.
(8) Patches in the queue get applied to the current alpha. This
implies a moving alpha, which one knows builds and passes all tests
on at least one system. It should be easy to upgrade to that alpha.
(9) People can (easily) donate computer time to build and test
alphas, which will greatly increase hardware coverage. Bisection can
be used to locate the offending ticket in case of failure.

4. Notebook: Admin

5. Notebook: Introspection

6. Notebook: "Modes"

7. Notebook: User Interaction

8. Notebook: Under the hood

9. Notebook: Development

10. Build / Test