Tech Committee Agenda 18 June 2013

From PKP Wiki
Revision as of 17:06, 13 June 2013 by CDL (Talk | contribs)

Jump to: navigation, search


  1. Welcome to our new at-large committee members: Bozana Bokan (Free University Berlin), Marc Bria (Autonomous University of Barcelona)
  2. Quick round of updates
    1. What have we all been working on PKP-wise?
    2. Any particular needs that the group can help with?
  3. At-large membership: one more member to invite
  4. 3 volunteers from members committee - Brian Owen has asked the Members Committee to appoint 3 people. We hope to have them on board soon, well in advance of the AGM.
  5. Reviewing our mandate, cont'd.
    1. Charge #1: provide technical input and advice on PKP’s software development methodologies and priorities. A couple of meetings ago, the group came to the consensus that PKP priorities and methodologies are unclear. We are working towards fixing this so that we can begin to give input.
    2. James has kindly provided a #Round up of documentation relating to PKP Priorities and Methodologies. Please read and we will discuss. What needs clarification? What would this information ideally look like?
    3. Barbara has taken a stab at organizing the PKP wiki so that this kind of info can be more easily found (see Main page - New). What do people think?
  6. Committee communication
    1. Google group -- any progress on finding out whether or not we can have a listserv hosted by SFU?
    2. There is a #pkp channel on -- come hang out! New to IRC? Read the IRC Help page or feel free to ask Barbara :-)
  7. PKP AGM and conference in Mexico City, August 19-21
    1. Who is going?
    2. What are our goals for the PKP Tech Committee meeting there?
  8. Next meeting: how about Tuesday 17 July, 2013?
  9. Anything else?

Round up of documentation relating to PKP Priorities and Methodologies


Publicly available:

-- general priorities are grouped into the general milestones chart:

-- each software application has its own individual roadmap as well, eg:

-- we have also started individual project pages to help track project progress, priorities, etc. and provide a clear location for pointing interested parties (eg.

-- we also collect and track bugs etc. in Bugzilla. There are several different priority markers available (priority, severity, version), but as a team we really only use the "version" marker to establish within what timeframe a bug should be completed (eg. all bugs marked 2.4.2 must be closed for OJS 2.4.2 release). We could probably do better here.

-- in terms of tackling development projects or bugs that have been brought to our attention from the community, we use a very ad-hoc method of determining priority, based mostly on subjective terms -- how often we feel something has been brought up, squeaky wheel, etc.

Privately available:

-- Asana for tracking internal PKP tasks and priorities.

-- Our own weekly meetings (PKP Developer meeting on Mondays; general PKP meeting on Fridays)

-- Various interminable Google Docs


Publicly available:

-- There's a fair bit of developer documentation on the wiki: This covers getting the code, contributing patches, interacting with github, etc. The documentation could probably stand a going-over and simplified, and needs to be promoted.

-- we have only recently cleaned up our patch submission guidelines to favour git, for example.

-- There's also the currently fairly out-of-date OJS Technical Reference ( While out of date, this is as far as I know the only place that gives a really good breakdown of PKP's coding conventions, the MVC framework that we use, and a thorough (though let's stress, out of date) breakdown of the OJS database. It may be worth considering how we adapt this document to the wiki, and to our other applications.

Privately available:

-- PKP also stores a fair bit of documentation on hosting practices, whether for our team (eg. how to install a journal on our servers) or for our clients (how to use the Custom Block Manager in conjunction with Static Pages). While most of our internal methodology should remain internal, the client-based documentation should be opened up to the wider community. It's the sort of questions we find ourselves answering over and over (how to set up DOIs; how to add content like a CMS) that our current documentation doesn't adequately cover.