IT Development/Progress meetings/Minutes 21Jan13

Attending

1. KB - Katherine Bavage (User:Katherine Bavage (WMUK)
2. MP - Mike Peel (User:Mike Peel)
3. DT - Doug Taylor (User:RexxS)
4. EE - Emmanuel Engelhart (User:Kelson)
5. TM - Tom Morton (USer:ErrantX)

Apologies

TM gave advanced apologies for unavoidable late arrival.

Progress Update

• Much has been done - email migration appears to have gone reletively smoothly, with the odd bug. Will look at making sure emails are being sent sucessfully.
• Blog migration in process - upgrading Wordpress but less urgent work. Something for February '12.
• Civi CRM hosting is migrated and has been tested. Now the largest job is moving to Drupal platform and most up to date version. KB noted important to plan timing not to clash with important work - EE will work on a parallel version and then KB test this until working - THEN migrate.

Plan to work collaberatively on testing - Mumble a good option. DT has admin rights for WMUK channel on a Mumble server if needed (relevent if multiple people as Skype scales poorly)

• Our Rackspace server hosting memory capacity has been increased to address slow page loading. Staff and Trustees need to report slow page loading for EE/TD to address bugs.

ACTION: KB to remind Staff and Trustees need to report slow page loading for EE/TD to address bugs.

ACTION: EE/TM to update page on UK Wiki to note change in capacity of server Done

KB noted this represented an increased cost but not enormous.

ACTION: KB to ensure in future a cost/benefit review of server arrangements undertaken and presented to Tech Committee for consideration following discussion of options.

- Tom Morton joined the meeting at this point

• Migratiation of DNS away from Mike's server to Gandi servers would happen shortly. Transferring the domains to Gandi may take a while - so suggest transfer to UKreg as an interim stage. MP asks that new servers having DNS capacity - TM noted not best practice to have DNS capacity tied to server infrastructure.

DT noted key determining questions; who is registrar and who are we using as name servers. It was noted that UKreg is the current registrar and it would be possible to get the DNS moved to this 'for now'. Nameservers running on MPs host currently.

DECIDED: TM to move the DNS onto UKreg - with a view to revisit other options in future.

ACTION: MP to pass appropriate details to TM

Operational

Issue tracking

• Katherine raised her concerns about RT being less useful for staff because they can't anticipate when various stages in development projects will be ready and plan their work accordingly.
• EE noted that timeline extensions/project management architechture might be overly complex for our organisational needs. However, he is familiar with Bugzilla and could support a change
• DT noted that it was important to be clear what sort of model was used for making requests -

1. Allow all staff and volunteers to make direct requests, then a more complicated system would have the capacity to deal with this.
2. The alternative is having a single point of contact from the staff team and trustee team, and channel requests through them.

Who decides priorities/timelines in this case...

• KB noted how channeling requests would impact on time
• MP noted that use of project management tool in QRpedia development would be useful in allowing members of the public and community a way to report bugs/share ideas. There was also the possibility of improving transparency by making timelines publicly available. KB agreed this was a good point, though reports of any identified security flaws would remain confidential.

ACTION:KB to work with TM to set up a parallel bugzilla install with a project management extension, and test by end of Feb.

DECIDED:Tickets before then to continue to be logged in RT and transferred to Bugzilla if agreed in next meeting to be a more effective system

Final migrations

This had been covered in Item 2.

Backups

• MP noted he had added this to agenda to consider the off-site backups of servers, and the safe transfer of a huge amount of data from old backups currently held on personal server - approximately 62GB.
• EE noted this is a significant amount of data. MP noted it was likely to be a lot of duplication from weekly backups over time. These were entire backups, hence data size.
• EE noted possibly a backup on hard disk would be less costly and fairly easy to manage. EE noted not clear what TM would propose in terms of backing up the VMs - a differential backup system on a daily basis may work.
• DT noted that further compression/zipping data may help and mean it could be stored on a large USB drive or the office server.

ACTION: USB drive or hard-disk needed - MP have a look at data and then advise KB on size of storage device needed.

ACTION: KB to research costs of fireproof safe to inform a decision about on and off site back ups.

ACTION: Tech committee to consider having more than back up locations as part of consideration of security strategy.

• DT noted the office server may have sufficient capacity if file size reduced, plus this is more secure in the sense of a kensington lock preventing the data from being removed. However, to establish if this is possible, KB would need to have answers to questions about external access to office network (server or machines). Whoever organises internet access for building should be able to assist (Ethical IT) If external access not allowed then would be less of an issue as would not have the choice to remotely access server install.

ACTION:KB to get details of of current set-up and ask about how this might block server access - can they ftp onto our network? Follow up on advisement with TM.

• MP notes IP edits from office are same, so may need to set up a port to one of the computers. DT noted that there may be an addtional layer of security in this. Will need to establish the exisiting set-up before we can plan properly for future back-ups and remote access.

Work programme

Security audit

• KB provided a brief verbal update of the current intent; to give staff a basic overview of the relevant policies and their implications (clean desk, remote access, physical security) and do a physical check of the office, ensuring appropriate software and physical security arrangements in place. It was noted that generally it was not expected that Trustees/Volunteers had as much access to personalised data and so there was less risk implied in their roles. However, there were obvious exceptions such as emails about major donors, private information about negotiations, or some data being shared.

ACTION:KB to work on some straightforward guidance for trustees as a simple overview/checklist MP to review - perhaps in collaboration with the community or Tech Committee (can certainly draft on-wiki)

• MP noted this could be included in trustee induction in future.

ACTION:DT noted that WMUK may need to review registration of data protection details in light of changed staffing and systems. KB to factor this in to ongoing security review work with TM.

Civi CRM

Planning around Drupal migration had been discussed under item 2.

• KB noted there were a series of minor and more major areas of work in connection with the database that needed progressing. Examples were:

1. Look at the Paypal API - not currently populating all the data correctly. MP noted that this was because it was dependent on how a potential donor arrived to a donation form - via a Civi form or via a landing page - this will be picked up by routing all donations through the civi page.

EE noted we need bug reports to log all issues.

1. Installation of the SmartDebit extension - something to consider installing in the parallel version?
2. Installation of the Gift Aid extension
3. Automation of thank you emails to donors

• KB noted that these issues had already been discussed on-wiki, but needed to be plotted more methodically in terms of how the database needed to progress. There was some discussion of the migration process and whether extensions should be installed on a parallel version and migrated, or installed post migration to Drupal.
• EE noted that clear ticketing and specification would help him plan the most effective process - needs clear specification of the usages of Civi CRM.

ACTION:KB log feature requests and bug requests in RT to mirror a global development page on wiki (rework the exisiting 'shopping list' page)

SAGE server

• KB noted that this needs to happen in terms of a secure install and queried the best way to log this.
• DT noted security concerns - better alternative installing on the server in the office? Not sure best arrnagement - get a Windows server installed and use that to run SAGE?
• EE notes no current planning page for this installation - can we set one up? This would help determine what set-up was needed

ACTION:KB liaise with RS to get specification of who wants to access and how. Then log as a job in RT/Bugzilla with a matching planning page on-wiki

Mediawiki/Wordpress improvements

• EE noted there are a few improvements to bring to mediawiki and then some bug reports and feature requests. Would like to progress with the improvements before moving to fixes, and so asked that bugs be directed queries through RT.
• MP noted that the US blog (GLAM wiki) is outdated. Needs looking at, and also that google analytics is installed on the US blog but shouldn't be.

ACTION: MP to log jobs via RT in connection with this as appropriate

Hosting UK Wiki on our server

MP has put together list of pros and con here

• It was noted the loss of Single User Login was a shame - could we ask WMF if we could somehow keep this? DT noted WMF hasn't ever made the SUL available to any other external wiki. TM advised would have to be within their infrastructure, and DT noted that an API could solve this, but if this hadn't been done already then unlikely to pick up.
• TM noted that Oliver Keyes had noted some plans to develop this in future.

ACTION: TM to contact Oliver Keyes and copy in tech list.

• It was noted noted there may be a concern about how user accounts are created and whether user account info would be stored in the SUL infrastructure - will WMF hand over data? Would we have to check with all account holders? MP noted that the WikiVoyage important may provide an object lesson in how to manage this

ACTION: Move the larger question onto agenda of tech committee and look into getting more information about the implications.

• DT noted this is non urgent - we can run for now as we exist. KB noted it would be good for us to demonstrate our ability to manage all our sites on our domain as a leading chapter, but that there was a lot of other evidence of this.

• DT asked about hosting project WikiMedicine - whether we would have the technical capacity to establish a separate wiki. MP noted that WikiMedicine is a US organsiation so if hosted in the UK, two sets of legal systems to consider if we host here in the UK. However, technically speaking creating the wiki should be relatively simple.

Role of the Technology Committee

• The idea would be to have a first meeting and flesh out the detail about remit on the page started by MP here
• Have Developers report back to the meeting, answer questions.
• EE noted in terms of structure - it would be optimal to provide strategies for the Tech committee to make decisions; not to research the strategies or provide technical expertise for the Chapter. The intention would not be to provide detailed technical documentation - but all info they need in a broader sense. This will speed processes up.
• MP noted the same sort of relationship being developed between staff and Trustee teams - between 'top level' thinking and operational delivery. MP noted that we would need to think long term as well - building WMUKs technical capacity to do software development would be an important concern for the committee,
• DT noted that members will have technical expertise, and may have less experience of a strategic approach. It would be important to keep the remit on track; acting as a conduit between board and community. Otherwise will have keen volunteers micromanaging or trying to deliver technical solutions.
• MP noted getting non Wikimedians on to the committee - GLAM or Mozilla - would assist with helping map out what do we need to get out of opportunities like QRpedia or funding development projects.
• MP will update as Tech Committee liaison to Feb meeting of the Board, and the Tech Committee meet in mid-to late February.

ACTION: KB to set up a Doodle poll to schedule a meeting of the Technical Committee in the week after the board meeting.

• In the first meeting the committee can discuss dates for the rest of the year of the first tech meeting which will be a telecon - but aim in-person meetings (tied to board meeting dates if possible)

Any Other Business

The next meeting would be at the end of February to follow on from Board and Tech Committee meetings.

ACTION: Katherine to send a doodle poll