Sprint Goals
This week, our sprint goals were defined as:
- User roles
- Resource content type
- Resources search / listing
- Site configuration page / theme customisation
Resource content type
The main focus for this sprint was the “resource” content type, the main content structure around which the whole site hangs.
We had a quick look at schema.org, to see if there was an obvious content model to follow for the resource content type, but the closest "thing" seemed to be the https://schema.org/Thing. (Since then, we’ve also noted the DigitalDocument, the VideoObject and the LearningResource, so we might evolve our content model once we've evaluated these.)
For our first pass, we've decided to stick with a single resource content type, which could have any of the types of resource inserted as the main resource item, text, document, video, audio. Our thinking is that this keeps the simplicity of a single content type with the consistency of the other metadata fields and also supports "blended content", content that might have web text, video content, PDF documents and images as part of a the resource item.
Installation profile
We've continued to build out the ‘resourcehub’ installation profile, and we’ve all got used to the new development workflow without too much trouble. It does take a little longer to add configuration to a Drupal installation profile, but it is very satisfying to see it grow and be repeatable and testable across installations. Testing the site install regularly after each piece of functionality lets us check it’s all still working and we haven’t broken anything when including new functionality.
Demo content
To speed up our development, for use in our sprint review, and for demonstrating the site in the future, it is really useful to have demo content available. We’ve addressed this by creating a custom ‘demo content’ module, building on the contributed default content module from Drupal.
Rather than the usual ‘Lorem Ipsum’ latin text, we thought it would make sense to use the optional demo content module to publish some best practice guidance around accessibility and content strategy, so we’ve been compiling the start of a library of useful content to both act as demo content but also as best practice.
In the long run, the idea is that this is an optional extension that can be enabled to see how the site works, but would not be enabled on a live site.
.09b17d9.75c0efa0ab55dc9bf608c49559a6adcb.png)
Bugs with the tests
Following best practice, we’ve been writing PHPunit tests as we go, to run whenever we create a merge request. This is an incredibly satisfying task, knowing that we are safeguarding against the errors of our future selves and other developers.
However, we have run into a few problems along the way this week. Unfortunately this is where tests can eat up time, for example when they fail on something that isn’t what you're trying to test! Luckily, the issues are often already documented by some of our peers in the Drupal community, with a patch that helps us work around the problem for now. Open source in action!
Sprint review
We invited our charity stakeholders to our sprint review meeting to demo and review the work so far. James took us through the process of installing the profile from the beginning, imagining he was Zeke, our Charity web developer persona. We then demonstrated the out-of-the-box demo content, searching and filtering and accessing a resource.
Logging in as a content editor allowed us to see the process of creating and editing the content and categories.
Realtime feedback
We were delighted to take many questions from the stakeholders which clarified needs, explained some decisions and even caught a few bugs! It is really rewarding to have such an engaged group of stakeholders helping to guide the project.
A lot of food for thought for the next sprint, and beyond.
This weelk we’ll be giving our charity cohort a login on the dev site to have a little play and provide more feed back, and will report back in due course.
The next sprint is particularly short with the bank holiday weekend, but we are hoping to make progress on the default styling and optional customisations.
Contribution guidelines and code of conduct
Following the lead of the the LocalGov Drupal project, we've started a merge request to establish baseline contribution guidelines. This was copy / pasted from LocalGov Drupal which in turn borrowed heavily from the Node Foundation's guidelines. Using a merge request to invite fellow collaborators to review such changes is a great way to spot mistakes and make improvements. In this case, Maria pointed out a couple of references to councils that I had left in and also noticed the mention of a 'code of conduct', which we don't have yet. The Node.JS code of conduct makes for interesting reading and is probably a great place to start.
Either way, the important thing is to establish such policies early to help to guide people who want to work together towards a collective aim. We can and will no doubt evolve these as we grow.
Keep in touch!
As always, feel free to get in touch if you have any questions or suggestions, email us at hello@agile.coop or find us on Twitter @agilecollective
