Skip to content

Team Meeting agendas and notes for 2017

Jump to bottom Edit New page
Ashley Engelund edited this page Oct 25, 2018 · 1 revision

Agenda for 18 Dec, 2017 (sprint 31)

Note items for discussion and put them in the "parking lot". That way we won't forget about it and we'll be sure to go over it in the meeting. Put your name in there so we know whose idea it is.

1. Scrum

2. Parking lot items

  • [Ashley] Lots of technical debt now that we know so much more about the domain, client needs, the code

    • Test need to be reorganized and reviewed for completeness (all kinds of tests: unit, functional integration, user feature/interaction)
    • code refactoring and clean up (small changes; refactoring within a class; refactoring into different classes/patterns)

  • [Patrick]

    • PR 438 - someone needs to test in IE.
    • Need indication of H-Branding status in an admin view

  • [Ashley] When and how to review the DinKurs spike? Optimally, we would do a group walk-through and discussion to review and then come up with a good design for actual implementation. But logistics (time-zones! sleep!) may not allow for that. So -- what can we do as a globally distributed project? Perhaps I should write up a few points about my thoughts and the design? Or maybe just have a meeting (HangOut or Jitsi) with whomever can make it and go from there?

  • [Ashley] Scheduling: Monday, 25 december? Monday 1 januari?

3. Review finished/delivered stories/chores/bugs

  • some PRs need 2nd reviews
  • some just need updating
  • Intermin deploy?
    • After PR 438 is tested and merged

4. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

Any pair programming that would be helpful?

5. Ready with client demo(s)?

6. Other items

Agenda for 7 Dec, 2017 (sprint 30)

Note items for discussion and put them in the "parking lot"

1. Scrum

2. Parking lot items

3. Review of SHF board meeting:

Caro, Bella, Suss + 1 more person. (jitsi)

Caro and Bella have both used our new system.

  • Suss will remind other board members to use it so we can get feedback

  • Caro's feedback: probably would have preferred to have 1 recommendation with different options presented, vs. having different options presented in parts

  • Susanna showed some about the administration abilities (people uploading documents, etc.) (was just an FYI demo)

  • SHF publicity campaign (this will be available at the big dog Expo): now has posters and graphics for publicity and marketing

  • there is a video that will be out

Still outstanding, but will have to wait until after the Expo:

  • agreeing to the 'terms and conditions' via the checkbox
    • 1 agreement for membership and 1 for branding? or is it 1 checkbox
  • explain the value of the H-branding
  • explain the value of the membership
  • info page about becoming a member (which may include the value of membership and value of company)

Patrick will create PT stories for #4 and #5 on the Business Rules... for H-Branding

We have plenty of SHF stuff to work on through the weekend. (Susanna will continue to be very busy with board and administrative SHF work and getting ready for the Expo.)

Open questions:

Agenda for 30 November, 2017 (sprint 30)

Note items for discussion and put them in the "parking lot"

1. Scrum

2. Parking lot items

  • Client DEMO tomorrow: Payments!

  • deployment [Ashley] Current deployment script will run db:migrate and fails. (I ran it on my DO server.) (Running db:migrate is one of the conventional steps when deploying with capistrano.)

    User no longer has is_member? method. So migration 20171025191957_add_member_to_users.rb fails because it does this:

class AddMemberToUsers < ActiveRecord::Migration[5.1]
  def change
    reversible do |direction|

      direction.up do
        add_column :users, :member, :boolean, default: false

        User.all.each do |user|
          user.member = user.is_member?
          user.save
        end
      end

      direction.down do
        remove_column :users, :member
      end
    end
  end
end

  • Should we instead alias is_member? so that the migration works -- until we decide how to handle all of this?

  • Refactoring [Ashley]: We should only load JS needed for the current page. Because we load all javascript files for every page, we are getting js calls for stuff even if we're not using it on the current page (e.g. maps, HIPS):

    • HIPS.js does a call on every page! https://api.hips.com/v1/tracker/ (Looks like they're reporting the IP address)
    • seems that there is at least 1 call to Google Maps stuff (Google Authentication service call)
    • this is _no_t high priority But this bugs me

3. Review finished/delivered stories/chores/bugs**

4. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

Any pair programming that would be helpful?

5. Readiness for beta testing payments (next week)

  • SSL cert installed
  • SHF HIPS account created
    • Channel 1: set to "live"
    • Channel 2: set to "test"
  • Beta testers identified

6. Other items

  • Client question: Email sent when an applicant is approved [Ashley] Should there be more text that explains the value of completing information for their company? (So that is is visible to the public?)

Agenda for 30 November, 2017 (sprint 30)

Note items for discussion and put them in the "parking lot"

1. Scrum

2. Parking lot items

3. Review finished/delivered stories/chores/bugs**

4. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

Any pair programming that would be helpful?

5. Readiness for beta testing payments (next week)

  • SSL cert installed
  • SHF HIPS account created
    • Channel 1: set to "live"
    • Channel 2: set to "test"
  • Beta testers identified

6. Other items

Agenda for 27 November, 2017 (sprint 29)

Note items for discussion and put them in the "parking lot"

1. Scrum

2. Parking lot items

  • [Ashley] Background jobs: It's time to talk about / decide on what to use for background jobs (Sidekiq + Redis? etc).
    Email notifications will make the server slow & users wait for emails to be processed and sent. Expected higher application usage given that we're adding features that members want and the SHF marketing campaign = more site visitors. All that means that we need to pay attention to what will make the server (and thus users) wait until something finishes processing vs. what can be sent to a background job/process.

  • [Patrick] Moving away from data management in migrations

  • [Patrick] Checklist for payments deployment

3. Review finished/delivered stories/chores/bugs**

Mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  • [Ashley] demo Exception Notifications (PR #402), including capistrano tasks rails:console and rails:dbconsole (PR #400)

4. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

Any pair programming that would be helpful?

5. Ready with client demo(s)?

6. Other items

Agenda & notes for 20 November 2017 (sprint 29)

present: Patrick, Ashley, Robert, Susanna

1. Scrum



Note items for discussion and put them in the "parking lot"

2. Parking lot items



3. Review finished/delivered stories/chores/bugs



4. Current Sprint work

  • Good discussion about migrations:
    • what should we do about migrations that are old and do up and down things that
      • once it's been deployed to production, then any logic for up and down doesn't really matter. But it can be helpful to keep in the code anyway (i.e. don't 'squash' or get rid of old migrations) so that we can look back and learn from them
      • not necessary to make sure that up or down logic work all the way back through all old migrations (schemas); only necessary to do them from where the last deployed migration is

Follow-up task(s):

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

Next client meeting: Monday, November 27, 2017 19:00 UTC

6. Other



Priorities

This is here as an explicit reminder so that if these are not the things we're really working on, we can talk about it.

  1. payments integration
  2. Dinkurs.se integration
  3. social media sharing
  4. e-mail system & emails sent out (must be finished by January 2018)

Notes for 16 November 2017 (sprint 29)

Questions for SHF Organization related to H-Branding

  1. Is the correct term for the availability of a member to access H-Branding rights a "license"?

  2. Exactly what rights does the license give to the member?

  • Use of SHF images?
  • Use of SHF name/image/website link/etc. in separate company-specific materials?
  • Other?
  1. Should we have "terms and conditions" (or similar legal language) for the license available on the website?
  • If "yes", should we confirm member agreement with the language before member can pay the license fee?
  • In the current payment process (email? paper invoice?) is there any related language (or link to website) for this purpose?

The next set of questions relate to how we should restrict member access to, and use of, the SHF member site, relative to payment of the license fee.

  • User vs. Member definitions

For background, please be aware that we will soon enable online (on the site) membership fee payments (for new and existing members). Also, here we refer to a person who is not yet a member, but has applied to become one, as a "user". This is distinct from a "member". Also, before a user can become a member, he or she has to 1) have an approved application, and 2) have paid the membership fee.

  1. If a user is associated with a new (to SHF) company, should the user also have to pay the license fee before becoming a member (that is, add a third requirement to those listed above)?

  2. Alternatively, should we impose a restriction on the use of the SHF website for any member associated with a company for which the license fee has not been paid (probably because the license fee term has expired and has not yet been renewed)?

  • If "yes", one proposal is the the company page is not visible to anyone other than the members associated with that company. (That is, the company will not appear in company lists, nor be shown on a map, nor show up in search results.)
  • what is the goal? for doing this?
  1. Other ideas for how to manage - and encourage - the payment of the license fee?

Error notification: ExceptionNotification, Errbit = 2 possible gems/tools.

  • Errbit requires separate Rails process(es) running (errors would be sent from SHF (Rails system) to ErrBit (Rails system) for tracking. Can the production server handle that?
  • ExceptionNotification is just that: simple notification of any errors/exceptions is sent out

Agenda & notes for 6 November 2017 (sprint 28)

We decided that we will go with Robert's proposed initial process for applications

Agenda & notes for 2 November 2017 (sprint 27)

present:

1. Scrum



Note items for discussion and put them in the "parking lot"

2. Parking lot items



  • next client meeting is on Monday, Nov 13 or Tuesday, Nov 14?

  • Exception Handling and emails were required in the real world this past week

  • time for ActiveJobs (for emails, then later reports, etc. ?)

3. Review finished/delivered stories/chores/bugs



4. Current Sprint work

Follow-up task(s):

(from Monday):
Ashley will come up with simple (!) sketch or mock-up of an admin's "Approve a Member" page that shows information/state for both the "membership application" and "payment status" so that we can have something tangible to generate more ideas and discussion. (Ex: we need to agree on some terms/vocabulary for the 'membership application including information uploaded by the user' and that (soon to be) separate process/state.

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

Next client meeting: ?

6. Other



Priorities

This is here as an explicit reminder so that if these are not the things we're really working on, we can talk about it.

  1. payments integration
  2. Dinkurs.se integration
  3. social media sharing
  4. e-mail system & emails sent out (must be finished by January 2018)

Agenda & notes for 30 October, 2017 (sprint 27)

present: Ashley, Susanna, Patrick, Robert.

1. Scrum



Note items for discussion and put them in the "parking lot"

2. Parking lot items



3. Review finished/delivered stories/chores/bugs



4. Current Sprint work

  • Patrick demo'ed his work with Payments (WIP to explore models, processes, ideas, etc. towards the goal of having Payments in place by the end of the year).

    • Q: Currently, everyone's membership term goes from 1 January to 31 December (the calendar year). Is that how SHF wants it in the future? Or should the membership term be based on the date they paid?

      • Answer from client Susanna: Yes, the membership term should be based on the date they paid.
        Ex: If the application has been reviewed and OK'd and so SHF is just waiting for payment, and the member pays on 1 april [April] 2017, then their membership term goes from 1 april [April] 2017 to 31 mars [March] 2018.

    • An admin must be able to enter information about payment(s) for a user. Ex: a user (postal) mails in payment their payment. (Will hopefully be a very rare occurrence once payments with HIPS is in place.)

Patrick's demo generated a lot of really good discussion about the models: Recognizing that the overall member approval process consists of both reviewing the application materials and getting the payment. Up to now, these to business processes have not been modeled separately: We've used a simplified version of it that has the payment status as part of the (single) state of the member approval. Now it's time to separate those.

  • Discussion of the "user is a member" status: what should happen when an admin changes that. (Prompted by the dialog box where an admin can change the user member status and enter a note about it.)

  • if the user had been a member and so there is a Company created and associated only with that member, what happens to that Company? (currently it is totally deleted from the system)

    • If the user is re-instated, wouldn't it be best if the user doesn't have to re-enter all of the info (ex: customized info displayed)? Can we just flag the company is "ok to display again" ?
      • need to conform with privacy laws + legal rules about how long information can/cannot be retained.
      • need to understand how long to retain financial transactions (does HIPS take care of everything we need for this?)
      • would an email to the user be helpful? ex: "We're sorry that you haven't renewed (or paid). We're going to have to delete the company information in XX days. If you can renew/pay by then, you wont' lose that information. But if you renew/pay after that date, you'll have to enter all of that information again..."

  • What happens with multiple applications from a user in a single year? ex: a user has already been approved and thus paid for 1 membership.

  • refunds?

  • if an admin gives the user extra time to pay -- a "grace period" ... then what? (prompted by the dialog box where an admin can change the user member status and enter a note.)

  • Discussion of "payment" in Patrick's code/model. Should that really be "membership term"?

  • SHF goal: Every member gets more training each year and submits that information so that when they renew, they have provided proof. SHF admin(s) review this as part of the approval process for renewal

    • would it be helpful to send members an email x months before their renewal date to remind them that they need to be sure to get new training and upload that to SHF?

Follow-up task(s):

Ashley will come up with simple (!) sketch or mock-up of an admin's "Approve a Member" page that shows information/state for both the "membership application" and "payment status" so that we can have something tangible to generate more ideas and discussion. (Ex: we need to agree on some terms/vocabulary for the 'membership application including information uploaded by the user' and that (soon to be) separate process/state.

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

Next client meeting: Tuesday! We'll have a lot to demo. Need to review this on Monday so we're ready.

6. Other



Priorities

This is here as an explicit reminder so that if these are not the things we're really working on, we can talk about it.

  1. payments integration
  2. Dinkurs.se integration
  3. social media sharing
  4. e-mail system & emails sent out (must be finished by January 2018)

Agenda & notes for 26 October, 2017 (sprint 27)

present: Ashley, Susanna, Patrick, Ashwin.

1. Scrum



Note items for discussion and put them in the "parking lot"

2. Parking lot items



  • [Ashley] models
  • [Patrick] naming git feature branches
  • [Patrick] cleaning up the Wiki documentation 'table of contents' page (duplication)

3. Review finished/delivered stories/chores/bugs



  • Will keep add backups to Capistrano deploy scripts task open even though it's a 'background' task (low priority, work is sporadic) so that we recognize that it is still being worked on and that it takes up capacity (effort)

4. Current Sprint work

  • Patrick continues to work on the Payment Processing / HIPs work. PR # 390 Membership payment via HIPS (foundation code) is important to get reviewed and accepted because other PRs build on it.

  • Francis said he's back to working on his email PR #321

  • On Monday at our next team meeting, Patrick will show us the next iteration of work with Payments so that we can think about and discuss the models, approach, issues, etc.

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

Next client meeting: Tuesday! We'll have a lot to demo. Need to review this on Monday so we're ready.

6. Other



  • Ashley: Need to be sure to discuss and document models so that we don't go too far in implementing things without really discussing them.

    • Patricks' payment PRs are simple right now; don't create or alter models too much. But will soon (e.g. membership renewal)
    • Robert's work refactoring Users/Membership/Company stuff touches on it
    • Important to make sure we have the chance to discuss ideas to develop and work through them, and document them in the wiki. "Lo-Fi" is great; use whatever is easy and works. (ex: take a picture of a diagram you've sketched and upload it. Or: Simple bullet points and text.)

  • Patrick: Current git branch naming is cumbersome and info in the naming is not necessary

    • Most of the info we need about a git feature branch is captured in the Pull Request
    • We do need the PivotalTracker number so we know how a git branch relates to the work tracked in PivotalTracker
    • There are good git (visual) tools out there that can make it easier to work with git branches (vs. command line)
    • We'll change how we name branches to:
    [SHORT text description]-[PivotalTracker task #]

  • Patrick will update the documentation in our wiki (our README or CONTRIBUTING or whatever.)

  • Patrick: The home page in the wiki has duplication between the "contents" section and the list of information below. This is unclear and is getting out of sync. We agreed that there should be just one section (not 2). Patrick will clean it up.

Priorities

This is here as an explicit reminder so that if these are not the things we're really working on, we can talk about it.

  1. payments integration
  2. Dinkurs.se integration
  3. social media sharing
  4. e-mail system & emails sent out (must be finished by January 2018)

Agenda & notes for 23 October, 2017 (sprint 27)

present: Ashley, Susanna, Robert.

1. Scrum



Note items for discussion and put them in the "parking lot"

2. Parking lot items



  • Robert doesn't understand some of the current specs for the MembershipApplicationPolicy. We will try to sort this out in the context of PR 388 (prevent applicant from editing an accepted or rejected application)


3. Review finished/delivered stories/chores/bugs



  • Robert will update and merge PR 383 and PR 385 (membershipnumber on user show and index views) and mark them as finished
  • Ashley puts in a new story (https://www.pivotaltracker.com/story/show/152213928) about being able to check code before a PR is submitted (Danger, lint checks)


4. Current Sprint work

  • Francis has let Ashley know he is back to working on PR 321 (email admin when new application received)


5. Other



  • Susanna lets us know there is a big media campaign planned for SHF somewhere around January. At that time an influx of members is expected, so the e-mail system should be in place at that time.
  • Talking a bit more about priorities we arrived at the following timeline:

payments integration
dinkurs integration
social media sharing
e-mail system (must be finished by January 2018)

Agenda for 19 October, 2017 (sprint 27)

1. Scrum

Note items for discussion and put them in the "parking lot"

2. Parking lot items

  • [Ashley] We now have enough important functionality that we need a way to notify the main SHF administrator (owner?) and developers if something goes wrong. We can do this with the ExceptionNotification gem. We have to decide what ways should the main SHF admin and developers be notified? and set those up. (Email, Slack, ... ?)

    • Ashley will talk with Susanna (thesuss) about what email address(es) to use, maybe setting up Slack for SHF, etc.

  • [Patrick] Working on Payment Processing and HIPS: will close the current Spike PR since that learning/investigation is 'done'. Will open PRs and mark them as WIP as needed. This is the start of a major piece of functionality. May deploy some foundation pieces might not have a way to be 'used' and then build on them as models, etc., are developed.

  • [Robert] Need to clarify the business rules and models for a Membership Application, Company, and Person. (Grew out of thinking more deeply about MembershipApplications and Companies and pushing beyond the simple way of modeling things we've had with MembershipApplication.)

    • What is the relationship between a single MembershipApplication and a Company?
    • Is the missing piece an "Employee" model? (a User can be an Employee for many Companies and thus have many and different "BusinessCategories" (skills) for each different company? And thus a User can have one MembershipApplication (to SHF) and yet still be involved with many different Companies via their Employee role?

  • We'll discuss assigning points to chores and bugs in PivotalTracker

3. Review finished/delivered stories/chores/bugs

mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  • Ashley will deploy to production immediately after this meeting so the Patricks Hotfix PR #387 (In address "edit" view, hide tooltip if address != mail) can go live

4. Current Sprint Work: Review outstanding stories/chores/bugs

  • [Ashley] quick demo of the Danger gem. Anyone interested in seeing how the Danger gem can work and how to set it up can talk with Ashley and set up a time to do a HangOut/pair programming.

  • Ashley wrote up some possible User Stories on the Classes, Events, and Integration with Dinkurs wiki page so that we can start talking about them.

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

(next client meeting: ...)

6. Other items

PivotalTracker: Shall we Assign Bugs and Chores Points?

We decided that we will assign points to bugs and chores in PivotalTracker.

This is a bigger issue because once you change this setting in PivotalTracker, there is no way to go back to not assigning points to chores and bugs. (You cannot revert or 'unset' this.)

  • We will use PivotalTrackers Automatic Planning and watch and learn how it does Velocity (capacity) planning.

  • We now must vote on a lot more things! We will learn how this affects us as a team (is it a giant bottleneck or not such a big deal?) and adjust

  • We will use the AsyncVoter in Slack so that points can be assigned as quickly as possible (to handle all of our timezone and time-commitment variations)

  • If you need to start work on something (ex: because bugs need to be handled quickly), then assign it ZERO (0) points so that you can "Start" it in PivotalTracker.

    • This way you will not influence other people's votes what points they think should be assigned
    • Not such a big deal with chores and bugs, since the person working on it probably does really know how much effort is required
    • this is the tension between working on "push" Kanban-type capacity planning and "pull" type planning; in real life, you have both

Agenda for 16 October, 2017 (sprint 26)

1. Scrum

Note items for discussion and put them in the "parking lot"

2. Parking lot items

3. Review finished/delivered stories/chores/bugs** - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

4. Current Sprint Work: Review outstanding stories/chores/bugs

  • Patrick demoed his work with HIPS

  • We'll talk about "should chores and bugs be given points in PivotalTracker?" on Thursday

  • we should tag items in PivotalTracker to make it easy for people to jump in find something to work on:

    • people that have experience with Ruby, Rails, etc. but no knowledge of the domain
    • people that are novices to Ruby, Rails, etc. and no knowledge of the domain

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

(next client meeting: Wednesday Oct 18)

6. Other items

Agenda for 12 October, 2017 (sprint 26)

1. Scrum

Note items for discussion and put them in the "parking lot"

2. Parking lot items

3. Review finished/delivered stories/chores/bugs** - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

4. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

  • any pair programming that would be helpful?

5. Ready with client demo(s)?

(next client meeting: Wednesday Oct 18)

6. Other items

5 October, 2017 (sprint 26)

I've put in my status, etc., since I won't be able to make the meeting - Ashley

1. Scrum

Ashley:

  • Emails weren't working on Heroku because I had single quotes surrounding values for the ENV variables in the Heroku Settings. I fixed that and emails are now working on Heroku. So that PR (#359) is ready to be deployed. (I've set the .env file on the production machine).

  • I also put in PRs for the content and formatting for 3 of the other emails to send out. I originally just put them into the wiki, but realized that doing them each as a PR would ensure that they are reviewed (even though these particular ones had already been reviewed by Susanna), and so that any discussion and changes would be there for any future work/reference. (Those are now submitted into the /docs/... directory.)

  • Fixed the minor typo found during the client review of the emails.

  • reviewed PRs

  • Thursday should be another sunny, beautiful Fall day here. It's cool in the mornings but should get up to about 20C (69F).

  • fun weather factoid to pull out at your cocktail parties this weekend: So many butterflies are migrating through Denver that they lit up the weather radar yesterday! (link to Denver newspaper article) you're welcome

2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  • Ashley: "369,370,371 What emails are sent with MemberApp changes?" can be marked as "Accepted" since we now have (1) the wiki updated with that info, and (2) the content and formatting for some of the emails has been reviewed. As I note in the chore, when we're ready to implement the other emails, we can create a chore for the content and formatting if needed.

3. Current Sprint Work: Review outstanding stories/chores/bugs

Any BLOCKERs?

  • any pair programming that would be helpful?

4. Ready with client demo(s)?

5. Other items

  • Ashley: reminder about the change we just made with PivotalTracker:

    We changed the start of iterations to Tuesday since we often do accepting and and delivering on Mondays after client reviews. (The start had been on Saturdays.) I modified a past iteration so now they should line up pretty well with our real-life schedules.

28 September, 2017 (sprint 25)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Current Sprint Work: Review outstanding stories/chores/bugs

    Any BLOCKERs?

    • any pair programming that would be helpful?

  4. Ready with client demo(s)?

  5. Other items

    Patrick: comments in code

25 September, 2017 (sprint 25)

  1. Scrum Patrick: working on multiple addresses

    Robert: membership numbers

    Ashley: mail PR

    Susanna: worked on production 'errors'

  2. Parking lot items

    1. Robert: membership numbers - is there a format for them? Comes regarding sorting

      Susanna: No business constraints to the format.

    2. Patrick - demo'd current progress on multiple addresses

      main_address will need to review where it's used (another PR)

      • billing address since we'll be using HIPS for that, will we need billing address? or just let HIPS handle that?

        • Patrick will do a spike with HIPS to explore

      • address form

        • remove "all companies" link

      exporting: will need a mailing address

      migrating: how to handle mailing addresses for members?

      • what work will we ask members to do?

  3. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  4. Review current PRs

    • any blockers?
    • any pair programming needed/helpful?

  5. Other

    Found problems in deployment:

    • membership pages are being over-written each time the system is deployed
    • admin name is being over-written
    • PT bug entered (Ashley is assigned; this may have to do with capistrano deployment)

    Models need to be reviewed to identify any refactoring / better modeling (Patrick & Ashley feel strongly)

    • this happened b/c originally we were doing the "only put something in a model if the client explicitly expresses a need" + "let models develop organically, don't put things in there ahead of time"
      • this leads to exactly this problem (and now we have to endlessly chip-away at refactoring)
    • Patrick and Ashley and whomever else is interested can look at the overall design of the models now and identify refactoring / modeling changes (PT chore created for this)

  6. Move accepted stories (non client-facing) into Production

21 September, 2017 (sprint 25)

  1. Scrum

  2. Parking lot items

  3. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  4. Review current PRs

    • any blockers?
    • any pair programming needed/helpful?

  5. Use of Pivotal Tracker - revised approach

  6. Move accepted stories into Production

18 September, 2017 (sprint 24)

  1. Scrum

  2. Parking lot items

  3. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  4. Review current PRs

    • any blockers?
    • any pair programming needed/helpful?

  5. Use of Pivotal Tracker - revised approach

  6. NOTE - client meeting today

    • When will we merge accepted stories into Production?

  7. Retrospective - deferred

    • What is going well?
    • What could be improved?
    • Action Items

14 September, 2017 (sprint 23)

  1. Scrum

  2. Parking lot items

    • Icebox review (needed? label)
    • Question re address(es) for company

  3. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees [prior sprint]

  4. Current Sprint Work: review current PRs

  • any blockers?
  • any pair programming needed/helpful?
  1. Review outstanding stories/chores/bugs in the current sprint
  • any blockers?
  1. Prep for client meeting
  • review agenda
  • demos?
  1. Retrospective
  • What is going well?
  • What could be improved?
  • Action Items
  1. Other items(?)

7 September, 2017 (sprint 23)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees [prior sprint]

  3. Current Sprint Work: review current PRs

  • any blockers?
  • any pair programming needed/helpful?
  1. Review outstanding stories/chores/bugs in the current sprint
  • any blockers?
  1. Other items

24 August, 2017 (sprint 22)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees [prior sprint]

  3. Current Sprint Work: review current PRs

  • any blockers?
  • any pair programming needed/helpful?
  1. Review outstanding stories/chores/bugs in the current sprint
  • any blockers?
  1. Other items

August 21, 2017 (sprint 22)

  1. Scrum
  2. Review prior sprint (21)
  3. Review open PR's
  4. Review current sprint stories
  5. Prep for client meeting (August 22)

August 14, 2017 (sprint 21)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

    Any BLOCKERs?

    • social links: need info from Susanna
    • email: need content reviewed (Ashley @weedySeaDragon) needs to email screenshots
    • email wiki: Need Susanna (& client?) to review
    • Need to talk about Google Analytics with Susanna (@thesuss)

  4. Current Sprint Work

  • Matthew needed the .env file
  1. Other items
    • Upcoming major work is payment processing.

      • evaluation + how we'd work together

      • need to work on question in wiki prior to our next client meeting

July 27, 2017 (sprint 20)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

    Any BLOCKERs?

    • social links: need info from Susanna
    • email: need content reviewed
    • email wiki: Need Susanna (& client?) to review

  4. Current Sprint Work This sprint will still 2 weeks long (our usual length for a sprint), even though we won't be able to review it with the client until a bit later (due to schedules).

  5. Other items

    • Note that next client meeting is pushed back a week from when it usually would be, and will be on a Thursday August 10, 2017 18:00 UTC (= 20:00 Stockholm/CED)
    • Patrick will be on vacation next week. He'll be back on Monday, 7 Aug.

Thursday, July 6 2017

Patrick, Robert, Ashley. Susanna was able to join for the later part of the meeting.

  1. Scrum (Patrick, Robert, Ashley) [US holiday happened.]

  2. Review finished/delivered stories/chores/bugs

    • Robert investigated why we had such trouble with Javascript testing. See his notes in the PT chore. He'll continue to investigate the specific problem(s) that remain with Javascript & testing (ex: random failures seen when running tests x times)

  3. Review outstanding stories/chores/bugs in the current sprint

    • lots moved to the next sprint [19] since the US holiday meant less work than 'usual'
    • Ashley: getting mail working with Mailgun looks easier than first thought. Ashley will

  4. Review agenda for client meeting

    • Upcoming client meeting is confirmed with both Susannas for July 10, 2017 18:00 UTC (= 20:00 Stockholm/CED)
    • demos:
      • Admin enters reason for "waiting for info from user"
      • Show both contact email and user login email on the 'user details' (#show) page

  5. Other:

    • With new people joining the project (yay!), we have feedback and information about what we need to do to better document our processes and info for our project. Ashley will spend some time to improve our documentation and project info.

    • Ashley will spend some time doing some user story grooming in PT and making a pass to improve

    • Noted in general: We haven't been doing retrospectives. In PivotalTracker, if something is in a previous sprint, we don't typically go back to discuss it as a team.

Next team meeting: Monday, 10 July at 16:30 UTC (before the client meeting)

Thursday, June 22, 2017

Question for Susanna - ship "waiting for info" as-is, or wait until custom reasons are added to DB.

Monday June 19, 2017 (sprint 17)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs

  3. Review outstanding stories/chores/bugs in the current sprint

  4. Review agenda for client meeting

  5. Prep for demo at client meeting

Monday June 12, 2017 (sprint 16)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

moving to Ruby 2.4

  • 'rebase' or 'merge'
  • moving to 2.4.1 : had issue with backup gem; (resolved)

moving to Rails 5.1

  • do things in small step

  • also need some known process for updating Ubuntu packages

    • not critical right now; just need a known way to do it

Patrick todo: move to Ruby 2.4.1, then can move to Rails 5.1

other

User feedback:

  • need multiple addresses: having a visiting address (= the address that a website visitor sees when looking at a company), a billing address, a postal address
  • should we adjust our priorities

Hips payment system (in Halmstad)

  • Susanna's experience with it in her job (Halland transportation )

    • were very responsive to issues
    • although Halland transportation decided not to use them, Susanna thought they were very good and would recommend to use them for SHF
    • is in Ruby
    • very new, local

  • when we're ready to review / evaluate, would be good to have a live meeting (Hangout, etc) to establish rapport, ask questions

  • if we use Hips, then would SHF be on their website? Is that of interest / ok with SHF?

  • We need a list of evaluation criteria for Payment system

    • fees and costs
    • support criteria
      • developers
      • users
      • SHF as an organization
    • use SWISH
      • is the Hips API with SWISH 'more' secure?

Next / upcoming client meeting

  • priorities:

    • addresses

  • Hips payment system feedback

  • Building data for tests

    • creating data for test is getting big and complicated
    • need to review how we're doing it. Do we need additional ways? restructure some?
    • ex: data factories / background
    • Patrick will make PT chore

  • Rails 5.1?

adding pagination to other models (users, etc)

  • something to think about

  • CI Semaphore test statistics have changed (lost)

  • Bug: Nav menu: when logged in as a member, link to edit your Company doesn't work

    • need to ensure we have a feature test to this
    • users can't easily update their address

Thursday June 1, 2017 (sprint 15)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

    • Lara T was able to join us to add Patrick and Ashley to the Semaphore collaborators
    • Patrick will try to change the semaphore settings to run RSpec & Cucumber tests in parallel
    • Ashley will figure out the implications (costs, limitations) for setting up and transferring the project ownership to a semaphore organization

  4. Current Sprint Work

    Any BLOCKERs?
    a few, noted in Pivotal Tracker

  5. Other items We'll move the meeting times for both Monday and Thursday 30 minutes earlier. Was 17:00 UTC, will now be 16:30 UTC

Monday May 29, 2017 (sprint 15)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

Robert: Questions about Membership Application state changes: waiting for payment, accept <-> reject. (He wrote them in his PR). Susanna clarified

  1. Current Sprint Work

    Any BLOCKERs?

Susanna has confirmed email registration. She'll work with Patrick to figure out if that's resolved and if not, what's next for them to do.

  1. Other items

  • Can we move the Monday meeting time so it's 30 minutes sooner? Robert has a conflict.

    Ashley has the AV Agile Book Club podcast discussion/recording right before the Monday meeting. She'll see if that can be adjusted.

May 25, 2017 (sprint 15)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

  • Why aren't production logs happening? PT task

rails_12factor gem redefines what is done with logs (sends them to STDOUT). What part of this gem is really needed? Patrick and Ashley will work on this

  1. Current Sprint Work

BLOCKERs: Need Susanna to confirm the email registration so that work can continue getting email working.

  1. Other items

  • We really must get control of our config and sysAdmin so that we can understand how things are set up and get things configured as they need to be.

    • GitHub (collaborators, managers, etc)
    • Semaphore CI builds (split into parallel jobs)

    After she finishes her current features, Ashley will focus on these and other sysadmin/devops tasks and issues.

  • GitHub process: Only PR author should update the PR branch if it's out of date (prompted by a good question from Robert)

    Up until now, if a PR branch was out of date because the develop branch had been updated (e.g. PRs were merged into it) and it seemed like changes would not cause problems with the PR, anyone could push the Github "Update Branch" button. But that's not really a good practice.

    The author needs to always review the merges in case it breaks something or has an unintended side-effect. (We have had some occasions where GitHub’s “automatic” merging caused problems.)

    So that’s a change: The author of an out-of-date Github PR needs to pull the latest develop branch, merge their PR branch with develop (and ensure that merge doesn’t break something), then push their updated PR branch back up to Github.

May 18, 2017 (sprint 14)

We'll meet twice a week on the hour:

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  • Robert will fix seeds.rb problem: creating multiple MembershipApplications (should instead just change state to generate a 'history')
  1. Review outstanding stories/chores/bugs in the current sprint
  • moved things forward to sprint 15

  1. Current Sprint Work

  2. Other items

  • Ashley: github permissions, include sprint number in the branch name

  • Status of what membership applications were or were not actually deleted: Members with expired memberships (owe payment) were not deleted, but have been emailed

Client meeting: MONDAY, May 22, 18:00 UTC (= 20:00 Stockholm/CED)

  • question for Ulrike/ SHF: If a person works for 2 different companies, must they submit 2 different membership applications? And if so, does that mean they need to pay twice?

May 13, 2017 (sprint 14)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

  4. Current Sprint Work

  • SHF Admin selects or enters a custom reason for why SHF is waiting for an applicant to respond (Ashley)

    • discussed different ways to store the reasons. Will store them in the db and will handle localization/i18n with a simple column that notes the language (instead of using the config/locale files). Pat suggested ways to record the 'custom' reasons entered in a text field and convert them to an entry in the db.

  • AWS account has been set up (Susanna). If/when Ashley moves or copies backup files there, she'll let the team know.

  • Mailgun account is ready (Susanna and Patrick). We're now ready to start implementing some functionality that uses email. Discussed different user stories that are candidates. User wants to reset their password seems the best user story to do first. (It's needed, and also small and well scoped.)

  1. Other items

  • In working with the real (production) data, Susanna noticed members that perhaps were deleted in the past, but are now showing up again.

    1. How can we look at the history to see if they were deleted (and if so, when?)
      • Ashley can look through the daily backups: production.log files and the data in the db (ex: uncompress and then grep for DELETE from "membership_application"...)
      • Susanna will talk with Ulrike
      • highlights the need to track history (see below)

  • Membership numbers: Previously, SHF had been tracking and assigning membership numbers manually. It's now time for this system to take that over

    • must ensure membership numbers are unique
    • assigned in sequence
    • will an admin ever need to edit the membership number? (perhaps)
    • need to explore edge cases and exceptions

  • Questions about which members/users have or have not been deleted raise the issue that we must now track events that happen with users and members so that there is a complete history that can be examined. Ex:

    • When was someone added? Deleted?
    • When was information changed? what was changed?
    • more than just noting the creation or deletion of an instance of a membership_application

    Must explore this and develop the user stories. Is probably large enough to be a milestone because it delivers substantial capabilities. (= more than just a few user stories and likely spans more than 1 sprint)

    • This will become especially critical when billing is done: SHF admins will need to reliably see the history of membership changes and payment history

May 5, 2017 (sprint 13)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in the current sprint

  4. Current Sprint Work

  5. Other items

  • New weekly meeting time: Thursdays at 7:30pm CEST, 1:30pm EDT, 10:30am PDT
  1. Reminders
  • Client meeting confirmed for Monday, May 8

March 31, 2017 (end of sprint 10)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in sprint 10

  4. Sprint 10 work

    • need to schedule time to review the AWS S3 cost estimate. Need to get board's approval to spend money because it's now critical to have backups and storage space. We're now going to have clients add their own data: customizing their company page. If we lose their work and don't have a backup, that will be bad. We also don't want to lose meeting minutes uploaded (or any other files uploaded). Here's the PT task

  5. Other items

    • Ashley did a show-and-tell of the "StoriesOnBoard" tool

    • We've provided a lot of capabilties for our users. They need time to really use them and then give us and SHF feedback

      • will mention this in the client meeting on Monday
      • this provides us with a natural opportunity to reflect and improve internal (debt) stuff (because we don't have features that immediately need to be done)

    • we talked about the need to review how we organize javascript, and how to handle loading order (when different scripts are loaded, at what point are they ready/available to be used?, TurboLinks), and a convention for naming and using them.

      • we are now using enough JS (with CKEditor and mapping stuff) that it's the right time to address this
      • Ashley recommends that we use the js-namespace-rails gem
      • sprint 11 or 12?

    • We now have some technical debt to address (lots of things are in PivotalTracker as chores).

    • We also have "project management debt":

      • need to do some grooming (review, organization) of PivotalTracker items
      • badly need to update how our project looks and the descriptions on AgileVentures
      • need to make sure we make it enticing and easy for new members to be involved
        • how to run the system (what it does, what it looks like; how to be a visitor, user, member, admin)
        • how to set up for development (tools, steps, getting data to work with)
        • how to participate in the project (how we use gitHub, doing a PR, working with PivotalTracker + GitHub, etc.)

  6. Reminders

    • Next team meeting: Friday, April 7 18:30 UTC
    • Next client meeting: MONDAY, April 3 18:00 UTC (= 20:00 Stockholm/CED).
      • Susanna confirmed the date & time with Ulrika
      • reminder to be ready to demo the features (we have lots to show!)

March 24, 2017 (start of sprint 10)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in sprint 10

  4. Sprint 10 work

    • need to schedule time to review the AWS S3 cost estimate. Need to get board's approval to spend money because it's now critical to have backups and storage space. We're now going to have clients add their own data: customizing their company page. If we lose their work and don't have a backup, that will be bad. We also don't want to lose meeting minutes uploaded (or any other files uploaded). Here's the PT task

  5. Other items

  • Ashley is evaluating the "StoriesOnBoard" User Story tool. She's set up a test board for SHF. You may have to sign up for a free evaluation account with Stories On Board. It can be integrated with PivotalTracker, but haven't done that so far.
    • goal of that test story board for SHF: see how it works for tracking real features and stories we're doing. (This actually tracks stories, not just the low-level tasks like PivotalTracker. It uses horizontal (priority and order ) and vertical (release dates and detailed tasks) organization

  1. Reminders

    • Next team meeting: Friday, March 31 18:30 UTC
    • Next client meeting: MONDAY, April 3 19:00 UTC (= 20:00 Stockholm/CED).

March 17, 2017 (end of sprint 9)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  3. Review outstanding stories/chores/bugs in sprint 9

  4. Sprint 10 planning

  5. Other items

  6. Reminders

    • Next team meeting: Friday, March 24 18:30 UTC
    • Next client meeting: Tuesday, March 21 18:15 UTC (= 19:15 Stockholm/CED).

March 10, 2017 (end of week 1, sprint 9)

  1. Scrum

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  1. Review outstanding stories/chores/bugs in sprint 9
  1. Other/Misc. (Please add items here if you have any)
  1. Reminders
  • Next team meeting: Friday, March 17 18:30 UTC
  • Next client meeting: Tuesday, March 21 18:15 UTC (= 19:15 Stockholm/CED).

March 3, 2017

  1. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  1. Review outstanding stories/chores/bugs in sprint 8

  2. Review questions for client

  3. Plan sprint 9

  4. Reminders

  • Next client meeting on March 6 - 18:30 UTC.
  • Next team meeting: Friday, March 10 18:30 UTC.

February 17, 2017

  1. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  1. Review outstanding stories/chores/bugs in sprint 7

  2. Review questions for client

a. Member address - Currently, there is no address attached directly to the member (user) account. Rather there is an address associated with a user's membership application. However a user can have multiple Applications, which could lead to duplication and errors in data entry. - Proposal - Add the user's address directly to the user's account. We could call this the "mailing" address or the "home" address - whichever is most appropriate. This address would be used for all membership applications created by the user. - NOTE: We want to be in compliance with Swedish privacy laws

b. Review the "All Users" view - What information would be helpful in assessing in managing users and user activity? - When we move the user address to the user account (from membership application) we will also be able to show user name and address (if useful).

  1. Plan sprint 8

  2. Reminders

  • Next client meeting on February 23rd, 18:30 UTC.
  • Next team meeting: Friday, February 24 18:30 UTC.

February 9, 2017

  1. Review Susanna's UI designs for company search/mapping

  2. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees

  1. Review outstanding stories/chores/bugs in sprint

  2. Reminders

  • Next client meeting on February 23rd, 18:30 UTC.
  • Next team meeting: Friday, February 17 18:30 UTC.

February 3, 2017

  1. Review finished/delivered stories/chores/bugs - mark as "Accept" (feature), "Deliver" (bug), or "Finished" (chore) if team agrees
  1. Review outstanding stories/chores/bugs in sprint
  • Discussion or clarification required?
  • Blockers?
  • Sprint plan change required? (e.g. move unfinished story to next sprint)
  1. Other Issues or Thoughts?
  • What should we do to be prepared for the client meeting? What do we want to accomplish in the meeting? How will we do it?
  • Retrospectives: We haven't been doing them. I know that there are things that I think need to be revisited and reviewed (because we now understand more about the system). I want to raise this so that we can think about how to work them in and take steps to do it. - ashley
    • Next retrospective: February 24th
  1. Reminders
  • Next client meeting on Sunday, Feb 5 at 19:00 UTC.
  • Next team meeting: Friday, February 10 19:30 UTC.
### January 28, 2017

  1. Establish / confirm standing (team) weekly meeting time (Fridays, at 19:30 UTC)

  2. Discuss sprint length (we had decided on 1 week at last meeting, but given that the client can only meet with us every two weeks it probably makes sense to have 2-week sprints)

  3. Establish standing bi-weekly client meeting (Tuesdays, 19:30 UTC)

  • (Susanna to confirm with client)
  • Next meeting: Feb 7, 2017
  1. Review finished stories - mark as "Finished" if team agrees
  1. Review outstanding stories in sprint
  • Discussion or clarification required?
  • Blockers?
  • Sprint plan change required? (e.g. move unfinished story to next sprint)
  1. Discuss and decide how to record business/system requirements
  1. Reminders
  • Next team meeting: Friday, February 3 19:30 UTC

BUGS found in production -- We should be sure to address this! (I'm not sure when or where to put this into the agenda. I don't want it too late because I want to make sure we have the time needed.)

Add a custom sidebar
Clone this wiki locally