Supplier Code of Practice

By sharing code, research, experience and good practice, we can make public services better and support a sustainable open source project.

Through this shared work, we aim to:

• make it easier for citizens to access council information and services
• help councils learn from each other
• reduce duplicated work and unnecessary costs
• develop tools that can be reused and maintained
• show how councils and suppliers can work together effectively

This code replaces the contributor agreement for suppliers. It sets out the values, principles and working expectations for suppliers involved in LGD.

This code of practice is intended to complement our code of conduct for suppliers working with LocalGov Drupal and related projects. It is not intended to replace or conflict with it.

Who this code applies to

This code applies to Certified Suppliers and those with Slack access.

Suppliers are responsible for making sure that employees, contractors and subcontractors working on their behalf understand and follow the relevant parts of this code.

Other organisations working with LGD are welcome to adopt the code as a statement of good practice.

How to interpret this code

We use must for essential requirements. Not meeting these requirements may lead to a formal review.

We use should for normal expectations. We recognise that reasonable circumstances may prevent a supplier from meeting an expectation.

When this happens, the supplier should explain the constraint and consider whether it can share related documentation, research, patterns or learning instead.

Our shared values and principles

We work in an open source community and want as many people as possible to benefit from it.

Suppliers taking part in LGD should support:

• working in the open
• sharing plans, experience and learning
• collaborating with councils and other suppliers
• developing and reusing good practice
• publishing work under appropriate open source licences
• maintaining a common codebase for projects agreed by the community
• including a range of voices and perspectives
• building a healthy and sustainable community

These principles should guide decisions about delivery, contribution, communication and how suppliers represent LGD.

What we expect from suppliers

Support the shared project

Suppliers should contribute to the long-term health of LGD.

Contributions can include:

• contributing code or modules
• Responding to questions on Slack
• improving documentation
• reviewing, testing and helping with merge requests
• triaging and contributing to issues
• sharing user research and service patterns
• carrying out accessibility work
• supporting events, meetups or working groups
• sharing knowledge with councils and other suppliers

We do not expect every supplier to contribute in the same way or the same amount. 

What matters is that contributions are useful, visible and support the wider community.

Work openly and share improvements

Suppliers should work openly and help keep shared improvements within the shared project.

Suppliers should:

• contribute improvements to the common codebase when they meet a shared need
• consider common needs when planning and building new features
• design work so it can be reused 
• tell the community about useful changes and enhancements
• discuss significant changes with the community at an early stage
• avoid unnecessary duplication of existing modules or functionality

Suppliers must not present a private or substantially modified version of any LGD product, including core, Microsites, or any other module or distribution maintained by the LGD community, as if it were the shared LGD product.

We understand that some work will be specific to one council. Contracts, security concerns or delivery timescales may also limit what can be shared.

Where work cannot be contributed, suppliers should explain why and consider whether they can share documentation, research, technical approaches or learning.

Work well with councils

Suppliers should help councils take part in LGD as active members of the community.

Suppliers should:

• encourage councils to join community discussions, meetups and working groups
• help councils understand the benefits of sharing work
• encourage councils to identify when a local need could become a shared improvement that benefits all users
• explain when work is likely to remain council-specific
• give councils the information they need to make informed decisions about custom development
• make councils aware of how subscriptions and the community fund support the shared project

Suppliers should not prevent a council from contributing work that can reasonably be shared, unless there is a legal, security or privacy reason.

Build around user needs and public sector standards

Suppliers should develop services around clear user needs and the practical requirements of councils.

Suppliers must:

• meet applicable accessibility, privacy, data protection and security requirement
• report security issues responsibly through the appropriate channels on drupal.org
• protect personal, confidential and security-sensitive information
• comply with the licences that apply to LGD and any other open source software used

Suppliers should:

• involve users in research and testing
• follow relevant public sector standards and guidance
• adopt an accessibility-first approach throughout design and development
• help councils understand risks, limitations and maintenance requirements
• avoid creating unnecessary dependencies on proprietary services.

Make code contributions practical and sustainable

Shared work needs to be understandable, usable and maintainable by people outside the organisation that created it.

Suppliers should:

• contribute work that addresses a clear user need
• follow agreed technical standards and patterns
• follow the Drupal community's policy on the use of AI when contributing to Drupal
• include enough documentation for others to understand and use the work
• include appropriate tests
• explain important technical or design decisions
• be clear about maintenance responsibilities
• respond to reasonable questions about contributed work
• avoid leaving unsupported code in the shared project without warning

Before contributing a significant feature, suppliers should discuss its purpose, approach and likely maintenance needs with the Product and Technical Lead.

Represent LGD clearly and responsibly

Suppliers must represent LGD accurately in proposals, websites, presentations, case studies and other communications.

Suppliers must:

• describe their role, services and relationship with LGD accurately
• avoid making claims that cannot be supported
• give appropriate credit to the councils, suppliers, community members and funders involved

Suppliers must not present, name, brand, market or operate their own services, products or websites in a way that could reasonably cause a council, prospective customer or other third party to believe that they are an official LocalGov Drupal service or product, or that they are operated, owned, endorsed or provided by LocalGov Drupal or the Open Digital Cooperative. 

This includes the use of the LocalGov Drupal name, branding, visual identity, domain names, service names or other presentation in a way that obscures the distinction between the supplier's commercial offering and the shared LocalGov Drupal project. Suppliers must use the LGD name and brand in accordance with the Drupal trademark policy.

Where a supplier offers commercial services relating to LocalGov Drupal, it must be clear and prominent that those services are provided by the supplier and are not services provided by LocalGov Drupal itself.

Suppliers may use "localgov-drupal", "localgovdrupal" or similar terms as part of a subdomain, or as part of the URL for a page within their own website, to describe their credentials, services or completed work, provided this does not conflict with the Drupal trademark policy and does not breach the principle above. For example, a page such as yoursite.com/services/localgov-drupal or a subdomain such as localgovdrupal.yoursite.com showcasing a supplier's own work is acceptable, provided it is clearly presented as the supplier's own service or portfolio, not as an official LGD site.

A standalone domain that is not part of a supplier's own website, such as localgovdrupal.fr, requires explicit permission from the Open Digital Cooperative board before use. This is separate from using LGD-related terms within a supplier's own site or subdomain, which does not require permission provided it meets the principle above.

Certified supplier status and involvement in individual projects must be described accurately. Suppliers must not imply endorsement beyond the status or relationship they hold.

Be transparent about funding and responsibility

Suppliers should provide the information needed to support trust and informed decision-making.

This includes being clear about:

• whether work is paid delivery, community-funded work or a voluntary contribution
• which organisation funded or commissioned the work
• who is responsible for maintaining a contributed feature
• any limits on what can be shared and the reasons for them
• significant dependencies on proprietary products or services
• potential conflicts of interest that could affect shared decisions

Commercially sensitive information does not need to be published. However, it should not be withheld when doing so would give a misleading impression about the work or the supplier’s relationship with LGD.

Certification of suppliers

This section sets out how suppliers become certified and how we review certification. It is based on the expectations in this code of practice and the next section on how we work with councils.

Certification is about how a supplier works with the community, not how much work they do. We look for evidence of open, useful contribution and close working with councils, rather than counting commits or tracking hours.

Routes to certification

New suppliers can become certified in one of two ways.

Direct certification

A new supplier can apply for certification if they can show:

• recent work with a local authority, supported by a testimonial or referee and
• evidence of contribution to Drupal, which does not have to be specific to LGD.

We will review this evidence against the expectations in this code, including contribution, openness, and responsible representation.

If offered certification, the supplier will pay the certified supplier subscription rate, adjusted for the remainder of the subscription year.

Community pathway

If a new supplier cannot yet show this kind of track record, they can join the community by paying a small fee for Slack access.

After six months of active participation, the supplier can ask to be certified. We will review their contribution over that period, including whether they have worked openly and shared improvements where appropriate, how they have supported councils to engage with the community, and whether they have met the expectations in this code.

If offered certification, the supplier will pay the difference between their current subscription and the certified supplier rate for the remainder of the subscription year.

Annual review of existing suppliers

We will have a review with all certified suppliers at least once a year. The review is based on the last six to twelve months of work, not on a fixed number of contributions.

We will consider how the supplier has contributed, including code, documentation, research, events, mentoring or other support, how they have worked with councils and encouraged them to take part in the community, and whether they have met the expectations in this code, including openness, transparency, and responsible representation.

Where a concern is raised about whether a supplier has met the code, we will take account of:

• the seriousness and effect of the issue
• whether it was a one-off or repeated problem
• the supplier’s size, capacity and role
• whether the supplier was open about the problem
• the steps taken to put things right
• the supplier’s wider contribution to the community

If a supplier has not contributed, we will discuss how they might contribute in the future (with a specific review date). If they still do not meet the code after the review, we may suspend or remove their certified status (and remove them from our website, other community platforms and assets).

Serious or repeated concerns may lead to:

• a formal warning
• a review of certified supplier status
• suspension or removal of supplier benefits or community roles
• removal from an official supplier listing

Any action will be proportionate to the concern. Decisions and the reasons for them will be recorded and communicated to the supplier.

We will keep this confidential, unless there is an ongoing risk to councils or the community that means limited, factual information needs to be shared.

A supplier may ask for a decision to be reviewed if it believes the agreed process was not followed or if relevant new information becomes available.

Any concerns about an individual’s behaviour in LGD community spaces will normally be handled under our code of conduct.

Any review will be arranged by the ODC board, either as a sub-group or a delegated group outside of the board,and all decisions will be signed off by the board.

Raising and reviewing concerns

If you are concerned that a supplier is not meeting this code, contact a member of the LGD core team.

Concerns will be considered fairly, proportionately and, where appropriate, confidentially. People with a material conflict of interest should not make decisions about the concern.

Changes to this code

We may need to change this code from time to time. We distinguish between minor and major changes, in the same way as our subscriber terms and conditions.

A minor change keeps this code accurate and up to date, without changing what is expected of suppliers, how certification is assessed, or how concerns are handled.

Examples include updating a link, reflecting a change of platform or process (for example, moving from Slack to another tool), correcting an error, adding a worked example for clarity, or restructuring the document for clarity. We can make minor changes without board approval.

A major change has a material effect on what suppliers must do to meet this code, how certification is granted or reviewed, or the consequences of not meeting the code. Examples include changes to the standards suppliers are expected to meet, the certification or annual review process, the grounds for suspending or removing certified status, or how concerns are handled or shared. Major changes must be discussed with suppliers and approved by the board before they take effect.

We will notify all Certified Suppliers by email of any change to this code, minor or major, including the new version number and the date it was last updated.

Where a change is major, we will give suppliers reasonable notice before it takes effect wherever practical, and will not apply a major change retrospectively to an anual review already in progress.