Website Team Roles

⚡️ Infrastructure Website
#1

A space to list all the roles within the website team.

It consists of three pools of developers, web liaisons and content admins, as well an External Coordinator who can prioritise the tasks and connect to other working groups, and a Co-coordinator who can step in when needed and take up the role on next rotation.

1 Like
#2

Mandate: Website Developer - DRAFT

Purpose (Task)

To develop features and fix bugs for XR Australia websites.

Accountabilities

  • Discuss tasks with website ticket admins
  • Scope out the technical requirements of tasks
  • Assign themselves website coding tasks according to priority
  • Develop fixes and features, submit for review as part of a pull request
  • Review other developer’s work, provide feedback and approve
  • Improve Continuous Integration and Deployment processes

Exclusive Control Over ( Domains )

  • Ausrebellion git repository
  • Ausrebellion staging server (as needed, not by default)
  • Ausrebellion production server (as needed, not by default)
1 Like
#3

looks great. For my understanding - re access to servers - am I right in thinking bits of code could be shared with ‘new’ devs then integrated by a ‘known’ dev into staging / live. Then once they’re full permissions they get full access?

#5

yes in a way. The two permission levels in gitlab are “maintainer” or “developer”. “Maintainers” have the most privileges and can push to ‘develop’ or ‘master’ branches from the command line, thus triggering a deployment to staging or prod respectively. “Developers” can only get their code into the develop branch by creating a “pull request” from the branch where they’ve been working on. For their branch to be merged into develop someone else needs to review pull request and approve it. Generally all the developers and maintainers should be doing this kind of review process anyway, just that those with ‘developer’ access have to do it. At some point if someone is developing a lot they will probably have to be promoted to “maintainer” to make it easier for them to work when no-one else is around to approve and it’s a small change etc.

#6

DRAFT - Mandate - Website Liaison - Website Working Group

PURPOSE

If I fulfilled my purpose, members of XR would have their requests for updates to the XR public facing website https://ausrebellion.earth/ responded to in a timely manner and actioned where appropriate, with consideration to the end user.

ACCOUNTABILITIES

  • For the days I’m rostered on:
  • Monitors the Ash-Website Mattermost channel [and TBC ‘ask-website@protonmail’] for requests to update the website content and functionality
  • Replies to the requester to confirm receipt and asking any questions required to understand the request
  • Enters requests as ‘issues’ in the ausrebellion project in GitLab, succinctly and using a user story format: ‘As a , I <person/group> would like so that . This may include requests for content updates within the existing structure of the website as well as changes to functionality or structure of the website
  • Escalates all urgent updates to the External Coordinator and Developer on roster via [method agreed with External Coordinator]
  • Assigns any major updates (eg change to main navigation or significant page layout changes) to the External Coordinator for discussion (though the Website Liaison may manage the project if desired)
  • Provides rationale to the requester for any website updates which are rejected and provides alternative solutions and contacts wherever possible
  • Labels issues, eg bug, CMS, high priority etc, to assist External Coordinator with comprehension and prioritisation
  • Reviews tasks once completed by Developers and Content Maintainers to check that user needs have been met
  • Communicates completion of the task to the requester
  • Schedules interim reviews to staging website on larger projects, in conjunction with External Coordinator
  • Passes on feedback and appreciation to the Developer
  • Attends a monthly meeting of Developers, Website Liaisons, Content Maintainers and External Coordinator to understand group capacities, needs and priorities

DOMAINS

TERM

The role Website Liaison is a member of the Website Working Group. The group has a rolling mandate. Members of the team may move in and out of the role with appropriate support and handover.

The nature of the role will be reviewed after six months and yearly thereafter.

#7

DRAFT - Mandate - External Coordinator, Website Working Group

PURPOSE

If I fulfilled my purpose there would be timely, accurate and user-centric updates made to the XR public facing website https://ausrebellion.earth/.

ACCOUNTABILITIES

  • Reviews GitLab tickets raised by all website liaisons to ensure clarity and assign back to website liaisons to gather further information where required, three times per week
  • Prioritises GitLab tickets by urgent / important on at least a weekly basis
  • Assigns development tasks to developers and simple, eg copy only updates, to Content Maintainers
  • When assigning tasks, considers dev/content maintainers skillset, interests, capacity and availability
  • Provides rationale to the requester for any website updates which are rejected and provides alternative solutions and contacts wherever possible
  • Sets timelines and milestones for larger projects with developers and works with website liaisons to schedule reviews on staging with the requester
  • Has a working knowledge of the front end, CMS and ticketing systems
  • Trains new Website Liaisons
  • Moderates a monthly meeting of Developers, Website Liaisons and Content Maintainers to understand group capacities, needs and priorities
  • Point of escalation for urgent updates or issues notified via [method agreed with Website Liaisons], together with Developer on roster for that day
  • Provides support to Website Liaisons via email and phone calls
  • Ensures each day has an assigned Website Liaison and at least three days per week has an assigned Content Maintainer and Developer
  • Engages accessibility specialists for website review every year, or before every major deployment
  • Attends XR meetings eg Media and Messaging; Talks and Training, as representative of Website Working Group to facilitate communication between teams and across the rebellion
  • Passes on feedback and appreciation to the Website Working Group
  • Communicates non working days and holidays as soon as possible to arrange a Website Liaison to operate as the External Coordinator for that period

DOMAIN

  • https://code.organise.earth/xr-australia/ausrebellion-gridsome/-/issues
  • Major updates to the website eg change to main navigation or significant page layout changes to be a) taken to the website working group b) posted as a thread on base/infrastructure and c) checked for compliance with accessibility requirements with an accessibility expert; for review and feedback ahead of deployment
  • References the website as a public facing domain and does not action updates which could put XR or its members at risk

TERM

The role Website Liaison is a member of the Website Working Group. The group has a rolling mandate. Members of the team may move in and out of the role with appropriate support and handover.

The nature of the role will be reviewed after six months and yearly thereafter.

#8

DRAFT - Mandate - Content Updator - Website Working Group

PURPOSE

If I fulfilled my purpose, changes to the XR public facing website https://ausrebellion.earth/ which do not require a developer skill set, would be made accurately and in a timely manner, with consideration to the end user.

ACCOUNTABILTIES

  • For the days I’m rostered on:
  • Reviews tickets assigned as ‘CMS’ in the AusRebellion Gitlab
  • Implements content changes within the existing functionality and structure of the website, for example
    • Adding / editing news items on the News page
    • Adding local groups and updating local group contact information on the local groups page
    • Correcting grammatical errors and spelling mistakes
    • Updating links where new materials exist
  • Assigns tickets back to the Website Liaison on roster for QA and communication of completion to the requester. Where the Content Updator is also operating as the Website Liaison for a ticket, assigns the ticket to the next Website Liaison on roster for QA and communication of completion
  • Attends a monthly meeting of Developers, Website Liaisons, Content Updators and External Coordinator to understand group capacities, needs and priorities

DOMAIN

TERM

The role Content Updator is a member of the Website Working Group. The group has a rolling mandate. Members of the team may move in and out of the role with appropriate support and handover.

The nature of the role will be reviewed after six months and yearly thereafter.

#9

Thanks for setting this out, Rene. A couple of follow up questions to help me understand how things work.

  1. Could you spell out what is meant by ‘branch where they’ve been working’?

  2. I’m also curious about the way staging and prod are currently being used. Are draft changes supposed to be made to the development server, and then checked by someone with ‘maintainer’ access before they go live on the production server? That would be the process I’d expect. But it looks like sometimes changes are made directly to the live site, which could be problematic.

So, would the Content Maintainer (as we’re currently using the title in the draft role) have the higher level access and therefore be able to bypass processes if it suited them? Signaling the risk involved in the role as currently envisaged.

#10

DRAFT - Mandate - External Coordinator, Website Working Group
Thanks for your fantastic work on this Sarah. The process appears constructive, thorough and clear to me as a person without tech background - will leave tech comments to others. From a regen focus - flagging we need to keep an eye on the time commitments for the role re training web liasion crew and dealing with emails / phone calls on ad hoc basis.

#11

DRAFT - Mandate - Website Liaison - Website Working Group and Content Updater role
Thanks for your fantastic work on this Sarah. As in my comments re External Co-ordinator role -I will leave tech comments to others. One question, re recruitment for both these roles : can someone be rostered on for a single day per week and any ideas of the hours of work per week - I know this would be an estimate only

#12

Hello Val, thanks for taking the time to review.

In terms of #hours and days:
Website Liaison: yes, they can be rostered on for a single day. I would say a minimum for the day would be to check for incoming requests and progress on existing tickets in gitlab (ie to review and feedback / approve) once per day, though ideally they would check a couple of times a day. Very similar to the way the ‘Talks and Training calendar’ team works. Of course as you state, the #hours would vary depending on the requests which come in and the amount of tickets which would be worked on, but I would say no more than an hour per day.

It will be important that once Website Liaisons are trained up on the basics, that one or several start to take on the more ‘proactive’ parts of the mandate ito identifying improvements to the site, logging those as tickets and managing them through development to live. This will start to blend with the responsibilities of the EC and will also provide support for the EC should they be absent.

In terms of External Coordinator:
There needs to be an ‘escalation protocol’ set up, for example if the website goes down. This for the devs too. At this stage nothing like that is in place so will need to be discussed at the working group meeting.
I would say that the EC role can be done over a few days a week rather than ‘always on’ with the exception of any ‘escalations’.
Hours I would say minimum 2hrs x 3 days (including supporting website liaisons), plus website working group meetings.

The proactive updates eg planning updates to the structure and design of the website and sourcing more content, plus meeting with other working groups would be on top of that and can be directed at a pace set by their availability and the wider avails of the website team ie designers, devs. At this stage, when there’s lots of opportunity to improve, I’d say anything from 5 hours a week to full time.

Does that make sense? Happy to set a time to discuss.

1 Like
#13

Hey Viola! re 1. what developers should generally do is to create a working branch from the ‘develop’ branch which is is related to the fix or feature they are working on. For example, there was a branch called “fix/121-events-image-scraper” referencing the issue number 121. All the changes done on that branch should relate to that fix. When it is ready, it will be merged into the ‘develop’ branch via the ‘pull request’ process.

1 Like
#14

Re 2, draft changes are made on a working branch and tested locally. Then they are merged via a pull request which requires other developers to review it. When they approve it does into develop. When develop has been tested and is in a stable state it gets merged into master which deploys it to production. Maintainers are the only ones that can do the merge from develop to production.

1 Like
#15

Thanks @rene.brisbane for 1 & 2. Just found this. Very helpful. Good to know an approval process is built in. And … sounds to me like the processes and permissions work more like website processes and permissions than the way a Content Management System works (at least in my experience). i.e. limited to content only, not allowing coding changes with potential to change the functionality of the website and with roll back potential to cope with errors.
For y’all, especially, @rene.brisbane, @Hobbo and @Wattlemoss to consider: Given levels of permissions and for ease of recruiting, and since there isn’t a true Content Management System, I suggest we don’t proceed with the ‘CMS Updater’ role as I’d originally envisaged. Might be better to just have the Web Liaison role in the non-tech group. Also consider giving the External Coordinator ‘Maintainer’ access to be able to check and publish content changes as well as giving designated Devs ‘Maintainer’ access. How would that work for all?

#16

@viola @rene.brisbane @Wattlemoss

So here’s my summary of the above, and suggested updates to mandates and process which account for the permission levels:

STAGING vs LIVE
‘Development’ is the same as ‘Staging’ site ie where changes can be checked before pushing live
‘Production’ site is the same as ‘Live’ site ie where approved changes are pushed to live

SIDE NOTE: I imagine due to permissions it technically possible to make changes direct to the live site, but we don’t want this happening due to chance to cause errors on the live site + requirements to keep staging as close to a direct copy of live as possible.

PERMISSIONS

  • ‘Maintainer’ (from a permission pov, not a role pov) are the only ones who can deploy from staging to live.

PROCESS
Devs update code (simple eg copy update (previously ‘Content Updator’) or complex eg functionality update (‘Developer’)) > request push to live > ‘Maintainer (permission level)’ deploys from staging to live.

PURPOSE OF ROLES (as I see it)
External Coordinator:

  • Oversight
  • Prioritisation
  • Liaison with groups external to website

Website liaison:

  • Liaison with XR members re requests
  • Raises tickets in Gitlab
  • Checks on staging

Developer:

  • Development tasks simple eg copy update (‘Content Updator’)
  • Development tasks complex eg functionality (‘Developer’)

SUGGESTED ROLES / PROCESS
No need for ‘Content Updator’ as permissions are the same for Dev as for CU. The mandates were differentiated by the type of tickets each can action. I agree to remove the Content Updator and have ‘Developer’ only. Tickets can be picked by any ‘Developer’ who has the adequate knowledge to perform the task ie simple or complex.

I do think it make sense for WL rather than EC to check tickets have been completed satisfactorily via check on staging site, given they have the full knowledge / background on the request.

Suggestion for change to process: following ticket approval by a WL, they are moved to an ‘approved, for push to live’ board on Gitlab.
Anyone with ‘Maintainer’ permission can then push live.
Maintainer permissions can be given to ‘Developers’ who have the appropriate level of experience.

If agreed, we would either need to expand the ‘Developer’ mandate to include simple updates.

This keeps the EC focussed on their priorities as outlined above.

We have our website meeting tomorrow (Fridays at 11.00 AEST (Brisbane) 12.00 AEDT (Sydney/Mel), 11.30 (Adelaide), 9.00 am (Perth) ) so shall we discuss then?

SH

#17

Sounds good. Issues I see are
Dev workload and recruiting to dev role - not insurmountable