National Association of Writers and Groups (development site – not for public use – official site: www.nawg.co.uk)

Project: Devolution

Note that this project was cancelled.

Overview

This project involves the devolution of some or all of the technical responsibilities, relating to the National Association of Writers' Groups.

The devolution is from a single individual: Kevin Machin, the principal author and organiser of the project, to many volunteers. It's envisaged that these recipients of the technical jobs need not have particular hi-tech skills, in order to do their work.

The original project name was "Technical Handover", but this is misleading. It's a devolution of responsibilities, rather than a complete transfer. It will take some time to achieve and some of the more advanced technical aspects may be retained by the author, at least in the short to middle term.

Reasons ↑

In short:

• The current technician, Kevin Machin, resigned from the committee in December 2017.
• He also wishes to devolve some, or possibly all, of his technical, non-committee related responsibilities.
• There's always a risk when work has to rely on a single individual, or particular individuals.

More details can be found in the project justification.

Scope ↑

The technical responsibilities for NAWG currently involve quite a lot of work and a fairly wide range of activities. Details are given below. In brief, the list includes but is not limited to:

• Maintaining and developing the website's content.
• Maintaining and developing the website's technology.
• Maintaining the email system.
• Maintaining other communication and collaboration systems.

The detailed list includes but is not limited to the things in the following sections.

There's probably lots more I haven't thought of yet.

Email System

Maintaining the email system, including:

• Account and relay management.
• Message organisation, archiving and backups.
• Handling messages that are sent specifically to the web administrator.
• Handling messages that are "100" competition submissions or enquiries. Note that this item should not strictly necessarily be a technician's duty, but the current software makes it so.

• Handling messages that arrive via the website, for example:

  • From the contact form.
  • Moderation requests from the comments facility.
  • User administration requests, e.g. password changes.
• Dealing with junk mail.
• Tidying up sloppy message management.
• Dealing with the hosting company to resolve issues.

Other Systems

Maintaining other communication and collaboration systems, including:

• Staff meeting tools, such as TeamViewer and IRC chat software.
• Shared document facilities, such as Dropbox.

Website Technology

Maintaining and developing the website's infrastructure, including:

• Dealing with the hosting company.
• Domain and sub-domain management.

• Development and maintenance of platform and software.

  • Updates to WordPress core software and plug-ins.
  • Custom software, written in PHP, JavaScript and CSS.

  • Data building and management tools, e.g:

    • Converting membership list spreadsheet data into a format suitable for the website.
    • Converting "100" competition emails and attachments into web-suitable format.

• Account management.

  • WordPress logins.
  • File transfer accounts (SFTP).
  • Database access (MySQL).
• Security, privacy and data protection.

Website Content

Maintaining and developing the website's content, including:

• Writing and editing articles using markup (HTML).
• Uploading and integrating documents, images, media.
• Updating regularly changing areas, e.g. competitions, events, headlines.
• Updating data for generated/derived content, e.g. writing groups directory.
• Dealing with website advertisements.

More details on this are given below. The purpose of this section is not to comprehensively document the business of content management, but simply to give you an idea of the scope of what's involved.

Types of Content

Many people think of a website as simple a collection of linked "pages". The reality is that it's much more complex than that. The website has many types of content, including:

• Articles:

  • Posts – articles in various categories that accumulate over time. Akin to blog posts.
  • Pages – relatively static articles, usually for information and reference. Hierarchical but not categorised.
• Comments – feedback from visitors. Threaded.

• Media:

  • Images – photos and other graphics that can be included in articles and other content.
  • Videos – as above but for audio-visual material, e.g. filmed lectures.
  • Documents – can be embedded into articles, e.g. for reuse across several articles.

• Taxonomy:

  • Categories – hierarchy of subjects under which articles are organised.
  • Tags – subjects for cross-referencing articles over several categories.
• Links – both internal (for navigation) and external (linking to other sites).

• Widgets – various configurable content that can be placed in header, footers, and side bars, as well as in articles:

  • Navigation & search tools,
  • Recent articles & comments,
  • Information panels,
  • Advertisements.

In many cases, these content types can form a hierarchy. For example, categories can have sub-categories; comments can have nested replies.

Activities

There is also a lot more to content management than simply adding new material. Activities include:

• Writing and submitting new content.
• Uploading and integrating documents, images, media.
• Editing existing content.
• Reorganising content.
• Removing content.
• Updating regularly changing areas, e.g. competitions, events, headlines.
• Updating data for generated/derived content, e.g. writing groups directory.
• Dealing with website advertisements.

Time Scale ↑

It's important to note that there is no rigid timetable for this project. Instead, there are well-defined lists of goals to be achieved and associated tasks to be done. At least, there will be as the project develops.

In general, achieving the goals to acceptable levels of satisfaction is deemed to be more important than completing them by a specified date.

Quick Task/Goal List

• Project planning:

  • Set up wiki.
  • Announce to staff.
  • Collect feedback and discuss.

• Phase A – content management:

  • Build team.

  • Iteration A01:

    • Planning.
    • Activity.
    • Review.
  • Further iterations…
• Phase B – technology management.

Short Term

Committee Duties

As I've resigned from the committee, such activities are now taken on by others. Having said that, I'm willing to be a "helper" where time allows.

Specifically:

• The publications administrator duties should by taken on by others. Pam is currently doing this.
• The (non-technical) "100" competition administrator duties should be taken on by others. Pam is also doing this and Simon Whaley has agreed to help.

Non-Committee Technical Duties

In the short term, I will continue to handle these.

In the longer term, I want to devolve these to other staff. These need not necessarily be committee members.

At present, there are barriers to the longer term goals. For example:

• Website content management requires too many technical skills.
• There are no replacement staff (at present) with the necessary technical skills to take on my non-content related duties.
• Developing and maintaining the systems and software requires particular skills and poorly/sparsely documented) knowledge.

Stakeholders ↑

Short term:

• Kevin Machin – Project coordinator & current technician.
• Some of the current committee members – involvements unclear as yet.
• Additional volunteers – to be arranged.

Longer term:

• Recruitment and job distribution will be needed. Details to be discussed.

Here's a list of the people involved with the project.

Please let me know if you want to be involved or not.

Justification ↑

Here are some justifications for why this project was created.

Personal Reasons

Kevin Machin…

The main problem is time. NAWG related work was becoming an increasingly huge drain on my time. This, I believe, illustrates a more general underlying problem with NAWG staff: there is a very unequal distribution of work among the people concerned. In some ways this may be unavoidable to a certain extent, given people's other commitments, but it does put undue pressure on those doing relatively more work. As I recall, Pam very nearly resigned over such a matter.

The other problem, also time related, is that I was frustrated at the lack of progress in some areas, particularly the projects that would bring new features and benefits to the NAWG community. The workload for regular tasks did not permit these projects to be developed. This is possibly a problem with efficiency in general, but may also be a consequence of unequal jobs distribution. Project examples include: PayPal improvements, online forms, mobile device friendliness, improving search engine rankings, restricted areas for staff/members, discussion forums.

It is my strong recommendation that this issue of overwork be given serious consideration, before it affects others.

General Staffing Level Issues

The crux of the problem is overwork. This applies not just to the technical areas but in general across the association. Overwork leads to burnout which leads to resignation, which then compounds the problem.

There are not enough staff to carry out the required duties. Since NAWGFest 2017, there has been an effective net loss of three people.

• Marvin, Anne and Kevin have left the committee.
• Bernadette is no longer a competition administrator.
• Henry has joined the committee.

Even when there were more staff, the distribution of tasks was by no means even. Perhaps this is unavoidable to a certain extent, but this can lead to some individuals being overburdened.

Reliance on Specialised Knowledge

Managing the website currently requires a specialised set of skills. This has happened for a number of reasons, over many years, but now we're in a situation where those skills are a barrier to other people working on the website.

Simply handing over the reins to other specialist(s) would buy only time. In the end, it would not solve the problem; merely transfer the responsibilities. When the individual(s) move on, the problem would remain.

The idea of this project is to attack the problem itself, as well as to spread the workload between as many volunteers as is deemed appropriate. What specialised knowledge is required, will hopefully be documented along the way.

Original Proposal ↑

The original proposal made to the NAWG committee, regarding the devolution of technical responsibilities for the association, is available as a document.

It was written by Kevin Machin on 03-Feb-2018 and presented (by document, not in person) at the committee meeting held on 24-Feb-2018.

What Needs Doing ↑

Details to be discussed and documented here, but…

The two most obvious remedial actions for the under-staffing issue are:

• Recruitment.

  • Committee member(s).
  • Helpers.

• Redistribution of tasks.

  • Pam to pass on many duties, as agreed quite some time ago. Obviously, this has currently backfired, but I'm certain this needs to be done.
  • Kevin to pass on website content management. Before this can happen, barriers need to be worked on, which is what phase A of the project is about.
  • Kevin to devolve the technology management of the website. This is what phase B of the project is about.

Barriers ↑

Content Management Barriers

At present, there are a number of barriers to devolving the content management responsibilities. Some of these may be of a technical nature, which could require technical changes in order to overcome. Others may be of a nature where documentation and/or training might be used to address them.

The following list may grow, as we go about our discovery.

Technology Management Barriers

To be considered during phase B of the project.

Phase A – Content Management ↑

This is the first of two phases, A and B, for devolving the technical responsibilities for The National Association of Writers' Groups. To recap, the phases are:

• Phase A: Content management: devolving responsibility for managing the content of the website.
• Phase B: Technology management: devolving responsibility for managing the systems and software for the website and other information technology.

This section describes and provides plans for Phase A.

Goal for Phase A

By the end of this phase, the website's content should be able to be managed by a number of people, rather than a single individual with particular technical skills.

Revised Approach

Important: Due to insufficient interest in this project, it is in a stalled state. For this reason, there's going to be a change in approach, as outlined below.

The project plan in general seems sound, so it will not be broadly altered unless the need arises.

The main issues are the lack of stakeholders and lack of motivation. The following measures will be taken to address this:

• Kevin will no longer be responsible for any website content, with the following two exceptions:

  • The "100" competition, which is too technical for beginners to handle.
  • The writing groups directory, for similar reasons.
• This means the remaining stakeholders, along with anyone else who cares, will need to deal with website content.
• Kevin will continue to provide technical support for systems, software, backups, email and the like.
• Kevin will provide help and support for new content managers, where he can.
• Pam will not be a stakeholder, as she's also stepping down and devolving her responsibilities.

This will likely be a trial by fire and difficulties are bound to arise, but it's preferable to zero progress.

Next Steps

These will need revising in the light of the revised approach, described above.

These steps, although initially sequential in nature, will be done in parallel where possible.

• Generate ideas for initial methods of discovery. Some initial thoughts are:

  • Give stakeholders logins to the test site and simply let them play around.
  • Design specific content management tasks for people, aimed to be realistic but also to aid discovery.

• Plan the first iteration A01 – probably mostly discovery and requirements gathering.

  • Form a team of people to work on A01.
  • Approximate time scales.

• Carry out iteration A01. Details to be discussed, but probably along the lines of:

  • Identify barriers that currently deter or prevent content management.
  • Devise ways to break down or overcome these barriers.
  • Create tasks to address these.
• Document specifications, based on the findings of A01.
• Plan further iterations.

What's Content Management?

If you think content management is just about editing a few pages, you might be in for a surprise. There's a lot more to it than that. Please see the content management page for more information about what's involved.

Methodology

Here are some general preferences for how we go about the project.

Concerns

Here are a few concerns I have with phase A and with the project in general.

Parallel Activity

Discovery

This is where we work together continuously to find out what's actually needed, rather than what we think we need. Learning by doing, to my mind, is the only sensible way to gather our requirements and come up with specifications for what to work on.

Documentation

In many ways, documentation plays an important part of this project. Not just the documentation of the project itself, but general documentation about how to manage content for the website, so that people in the future can learn how to do it.

It's imperative that we document things as we go rather than after the fact. In my experience, "document later" very often means document never.

With this in mind, I'm attempting to evolve a [:manuals:website:start|website manual] alongside this project. As others get more involved, they can contribute to the manual too.

Learning & Training

Making the software and systems easier to use will hopefully minimise this, but the stakeholders of this project phase will need to learn things. There may be many ways to go about this, which are not mutually exclusive, for example:

• Learning by doing.
• Learning by reading documentation.
• Learning by training.

Unless the first one one the list is predominantly successful, then this could mean a great deal of work for the current technician to write the necessary documentation and devise and provide the appropriate training methods and material. This gives rise for another thing to add to the concerns for the project.

Specification

This provides us with clearly understandable definitions for what we need. In terms of project documentation, the specification may provide a focal point for what we work on.

Having said that, it's important to remember that we want an overall agile approach to the project, rather than getting stuck on the specification details – a symptom sometimes referred to as analysis paralysis.

Design

This is mainly for me, to help with the implementation of the project. However, I'll try to document things here, for those who are technically minded.

A more important aspect, will be to document the overall website design, rather than just the changes needed for this project. This will probably be more important for phase B, but some aspects may be helpful for content management as well.

Implementation

This is where I get on with things and get the website in a more usable state, in terms of content management.

Don't forget that this will be done in incremental, iterative steps. Don't expect it all at once.

Testing

This needs to be done by as many people as possible. The reasons should be obvious.

It's important to be aware that development and testing will not be done on the live website, so as not to disturb things there. Instead, the test website will be used.

Note: when not in use, the test site will automatically redirect visitors to the live site. If this happens, it simply means that no testing is currently under way.

Deployment

This is where approved changes are rolled out to the live website. Again, this will be done in incremental steps, as the project proceeds.

Phase B – Technology Management ↑

This is the second of two phases, A and B, for devolving the technical responsibilities for The National Association of Writers' Groups. To recap, the phases are:

• Phase A: Content management: devolving responsibility for managing the content of the website.
• Phase B: Technology management: devolving responsibility for managing the systems and software for the website and other information technology.

This section describes and provides plans for Phase B.

To be be completed…

Author: Kevin Machin ♦ Created: 17-Aug-2018 ♦ Access: public ♦ Article: project-devolution ♦ Topics: old WordPress site, website, projects