People

Agenda

  • Discuss and decide goals for this iteration.

Notes

  • My aim for this iteration is to get the controller to manage project information properly. This means reviewing the yarns and code related to the /projects end point, and fixing anything that needs fixing. This will be time-boxed, so that if I run out of time to fix, I will at least make a list of things that need to be fixed.

  • Additionally, I will start a new tool, icktool, which will provider a command-line interface to accessing the Ick APIs. Thinks curl, but with token generation added, and output formatting.

Current projects

Tasks for this week

Tasks may be part of a project or be random small ones (max an hour) that just need doing.

what project Who estimate(h)
Write icktool that can generate token icktool liw 2h
Review yarns for /persons projects-endpoint liw 2h
Reviaw code for /persons projects-endpoint liw 2h
Clean up yarns, code for /persons projects-endpoint liw 2h
Total liw

Task descriptions

  • Write icktool that can generate token: Add to ick2.git a new script, icktool, which can generate a token, and query /version. It should read a configuration file to get the necessary information so that the user doesn’t need to repeat things every time.

    Acceptance criteria: Assuming a correct configuration file, user can run icktool token to generate a token, and icktool version to get a nicely formatted vesion of the /version resource. A token is generated automatically, as needed, or can be provided by the user via a command line option, to avoid re-generating every time.

  • Review yarns for /persons: Read the current yarns for /projects, and make note of anything that seems it would be worth fixing.

    Acceptance criteria: I’m happy that after fixing the things I find, the yarns will be good, meaning they’re understandable by others, correctly specify the needed functionality, and completely test all the relevant aspects of the controllers handling of project information.

  • Reviaw code for /persons:Read the current code implementing /projects, and make note of anything that seems it would be worth fixing.

    Acceptance criteria: I’m happy that after fixing the things I find, the code will be good, meaning it’s clean, correct, has good unit tests, and has no major architectural or other flaws.

  • Clean up yarns, code for /persons: This is time-boxed: only spend the allocated time this iteration, and if there’s more to do, leave that for a future iteration.

    Acceptance criteria: I’ve fixed at least one thing off the list, and it’s committed, merged, and passes CI.