karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 399, assigned 8, needs-review 1

Two things:

1) I am currently doing some branch gymnastics with vgifts and wanted to record my process here.

Given one published branch "bug0215-submitted" which was just pulled into develop on Github, and another unpublished, temporary branch with additional changes waiting in the wings, here is what I did to update my original working branch with the new changes:

> git co develop
> git pull dreamwidth develop
> git co bug0215-submitted
> git merge develop
[note: here bug0215-submitted and develop are identical]
> git co (temp branch)
> git rebase bug0215-submitted
> git co bug0215-submitted
> git merge (temp branch)
[note: here bug0215-submitted and temp branch are identical]
> git branch -d (temp branch)

Now all of my new code is tacked onto my existing published branch and just needs to be pushed to my Github repository, along with the updated develop branch.

2) I cannot recommend GitX (http://rowanj.github.io/gitx/) highly enough for showing me at a glance how the state of my working repository changed with each command I executed above, giving me the confidence to proceed all the way through (gulp) deleting my unpublished branch.
karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 270, assigned 11, needs-review 3

Almost exactly six months to the day since my first submission, my backend code for vgifts has finally been committed.

Thanks to everyone who has reviewed my work up to this point: [staff profile] mark, [staff profile] denise, [personal profile] fu, [personal profile] alierak, [personal profile] allen, [personal profile] exor674, and [personal profile] sophie. You are my heroes.

Now I have to get cracking on the user-facing stuff...

I'm also thinking I ought to write a test suite for DW/VirtualGift.pm. It looks like Devel::Cover will help me answer the question of what to test by pointing out bits of code in the file that my tests don't execute.

Devel::Cover usage notes )
karzilla: a green fist above the word SMASH! (Default)

Bug counts: resolved 252, assigned 13, needs-review 9

I've spent some time today looking at DW::Shop::Item. I just realized it will already do stuff like delayed deliveries and anonymous gifts, which means I can reduce the original scope of my vgift transaction table to something similar to what is stored for rename tokens, except in this case it will need to contain all of the data to display the gift on the recipient's profile.

My current thinking is that a gift recipient should receive a notification that presents two possible actions: display the gift on their profile, or reject the gift. If no action is taken, the gift will be displayed on the user's "all my gifts" page but not on the profile. If the user chooses it to be placed on their profile, it stays there for some amount of time and then "expires". If the gift is rejected, the sender could be refunded the points spent for the gift. There should probably also be a window of time for allowing that, most likely the same window as for the profile display.

There was mention of allowing the user to manually delete a gift from their "all gifts" page but I'm not sure that's necessary if gift rejection is allowed up front.

Should the expiration window be site configurable? User customizable? I'm thinking yes/no but figured I'd throw that out there too while I'm brainstorming here.
Page generated Sep. 21st, 2017 03:14 am
Powered by Dreamwidth Studios