Board of Directors

About

This agreement outlines Finsweet’s initiative to create the Client-First Board of Directors voting system. Each Member of the Board is given votes based on their community impact in Client-First. Board of Director votes are used to determine all changes to the Client-First Style System for Webflow.

Purpose

Currently, Finsweet manages all updates and decisions for Client-First.

Client-First is a product for the community. The Board of Directors initiative is an effort to make Client-First not only for the community, but also by the community.

The Board of Directors (the Board) is responsible for updates and decisions regarding Client-First. This includes, but is not limited to, roadmap guidance, versioning direction, class changes, and official cloneable updates.

All decisions must be made in the best interests of Webflow users.

In order to achieve this objective, it is essential that each Member of the Board has the ability to contribute to the decision-making process, and that their input is valued and taken into account.

The Board of Directors is created based on the most influential and focused teams that use Client-First to grow their business.

Weighted Voting System

The Board of Directors follows a weighted voting system that is based on the Member’s influence on the Client-First ecosystem. The goal of this initiative is to ensure that the voting power of each Member is proportional to their community impact and contribution to Client-First.

Each Member of the Board of Directors is assigned a specific number of votes. These votes can be used when deciding new updates for Client-First.

The initial number of votes assigned to each Member of the founding Board of Directors is as follows:

• Finsweet: 5*
• Relume: 3*
• Finsweet+ Community: 1
• Relume Community: 1
• Client-First Translators: 1
• Twitter (Public): 1

*"Company Member" has the ability to initiate a “Vote Request”. These definitions are explained in the “Voting and Operating Procedures” section.

Companies can decide how to use their company vote power. For example, Finsweet’s 5 votes are a team-wide collective decision across 20 Webflow Developers. The decision of these 20 developers account for all 5 votes.

Companies who have community votes must follow the voting decision of their community. Community decisions cannot be overturned by the company. More information about public Airtable voting is available in “Voting and Operating Procedures”.

Scaled Voting System

As the number of Members on the Board of Directors increases, it may become necessary to adjust the number of votes assigned to each Member in order to maintain the integrity of the weighted voting system.

Each Member's voting power remains proportional to their level of contribution to the ecosystem, while also ensuring that the system remains equitable and effective as Client-First continues to grow and evolve.

In order to achieve this, Finsweet may periodically review and adjust the Members of the Board of Directors, as well as the number of votes assigned to each Member.

Finsweet will manage the scaled voting adjustments based on their best judgement and dedicated fairness to the system. If at any point, Members of the Board feel that Finsweet’s decision to adjust the Members or weighted votes is not fair, the Board of Directors can request a vote to decline Finsweet’s decision.

Voting and Operating Procedures

• Vote Request. A request to vote on a change to Client-First Style System. Only Company Members have Vote Request power.
• Company Member. A Member of the Board of Directors that is considered a "company", "organization", or "entity" that uses Client-First for primary business operation.
• Clear single voting objective. A Vote Request must be for (1) topic vote — For example, a vote to update classes in the spacing system. A Vote Request can not bundle multiple topics — For example, a vote to update spacing, typography, and core structure.‍

• Vote Request explanation requirement. When a company Member initiates a Vote Request, the Member must provide a public view-only Google Doc containing (2) types of explanation informing Members about their Vote Request. This Google Doc will be sent directly to Members of the Board of Directors, as well as shared publicly on community channels and Twitter. The explanations must provide sufficient information to help voters make an informed decision.
  _{- Explanation 1:} Clearly written explanation of the proposed change and available voting options.
  _{- Explanation 2:} Screen recorded video visually showing and explaining the proposed change and available voting options. The maximum video duration is 5 minutes.
• No suggestive voting options. When explaining available voting options, it is required to maintain a neutral point of view for all available options. It is prohibited to clearly favor a voting option to encourage others to vote for it. Options must be presented with equal weight, clear facts, and no bias or favoritism toward any option. This policy encourages fair and unbiased voting based on facts rather than sales tactics.‍
• Initiative a vote. A Vote Request is the only way to initiate a Board of Directors vote. There are no scheduled or recurring voting unless explicitly requested through a Vote Request.
• Submit a Vote Request. Vote Requests must be sent to Eve Kayser (Finsweet) and Victoria Perez (Finsweet). Send your Vote Request to [email protected], [email protected]
• Vote timeline. Board of Directors must vote on active Vote Requests within (1) week. Failure to place a vote within (1) week forfeits your ability to vote on the topic. Public voting through Twitter Polls is open for (1) week.‍
• Vote Request frequency. A Member can only use (1) Vote Request per yearly calendar quarter. For example, (1) request can be made between Jan-Mar, an additional (1) between Apr-Jun, an additional (1) between July-Sept, and an additional (1) between Oct-Dec.‍
• Vote Request for Global Embed improvements. A Vote Request is not required for CSS improvements inside the Global Embed. For example, if browsers now support a more efficient and widely supported CSS snippet for an existing Global Embed class, this change can be made without a Vote Request. "Implementation of Updates" procedures must be followed with any change to the Global Embed. This Vote Request override rule does not apply to new classes or implementation concepts within the Global Embed.‍
• No meetings. There are no scheduled or recurring Client-First Board of Directors meetings.‍
• Async communication in Slack. All discussions and voting take place asynchronously through text communication and screen recordings.‍
• Transparent voting results. Voting results are always accessible for all Board of Directors Members. No Board Member voting results can be made private. A third-party application, Airtable, is used to display all votes from Board Members. This Airtable database will be publicly accessible. Finsweet manages Airtable form creation, management, and account subscription of the account.
• Community voting. When a Vote Request is initiated, Company Members that manage community votes must collect votes through "emoji voting" inside their community channel. For example, Finsweet will post in the Finsweet Community Slack about the Vote Request, and prompt their community members to use an emoji on the message to submit their vote. This process will help prevent a user from submitting multiple votes. After (1) week, the option with the most emojis represents the community vote. Twitter (Public) community vote is handled through Twitter Polls.

Implementation of Updates

There is a (1) month timeframe between a Board approved Client-First change and the public implementation of the change.

During this (1) month timeframe, all parties who are affected by the changes have the opportunity to properly implement the changes and make any necessary adjustments to their products, tools, content, and resources.

Vote Request outcomes are shared immediately with all Board of Directors, as well as the public community. However, the public-facing implementation of these updates must be made no sooner than (1) month.

Members of the Board of Directors agree to not implement their changes before the (1) month timeframe.

This implementation period is critical to ensure all updates and changes are properly integrated into a Member’s products, tools, content, and resources.

Requirements to be considered for Client-First Board of Directors

• Product, tool, or content is mostly or completely focused in the use of Client-First.

• 1,000+ active users (SaaS product, Chrome Extension, or similar). Users do not have to be paid, but users must be active — as in  1,000 users are using the product month after month, for a minimum of 3 months, confirmed by analytics.

• 1,000+ active community members on one platform (Slack, Discord, Circle, or similar). The community channel must be active on a daily basis with conversations around product use and/or Client-First.

• 5,000+ clones of one Webflow project that directly promotes the use of Client-First.

When the threshold of active users, community members, and project clones is met, the Board of Directors will decide if the potential Member is considered "_{mostly or completely focused in the use of Client-First}". If the project is not mostly focused in Client-First and has other priorities, the potential Member may be declined from joining the Board of Directors.

It is required for all Company Members to maintain these accomplishments. For example, if a Company Member loses interest in Client-First and no longer maintains an active community or product, the Board can vote to remove the Company Member from the Board.

These requirements are subject to change as the community grows. Finsweet will make adjustments to these requirements based on their best judgement and dedicated fairness to the system. If at any point, Members of the Board feel that Finsweet’s decision to adjust the requirements is not fair, the Board of Directors can request a vote to decline Finsweet’s decision.

If you are interested in joining the Board of Directors, please reach out to a Company Member as soon as possible to express your interest.

Attribution Requirement

One goal of the Board of Directors is to bring unity to Client-First across all product providers. This includes unity of cloneable projects, style guides, stylesheets, and marketing material.

Company Members must clearly attribute Client-First on the homepage of the Member's marketing website. It must be clear that the product, tool, or content uses Client-First.

Company Members may use their own proprietary style guide, which may be different from the default Finsweet Client-First style guide project.

If a Member company decides to use their own style guide, the Member must make a visible Client-First attribution. Text attribution must be clear an placed above the fold of the style guide.

Attribution content:

• This style guide is based on Client-First and is a fork of the Client-First cloneable project.

The goal of this is to help the community understand that we are all part of the same family.

Conclusion

The Client-First Board of Directors is an important step towards making Client-First a truly community-driven product.

We can ensure the continued evolution and growth of Client-First benefits the entire Webflow community by giving each Board Member a voice in decision-making.

With this agreement in place, we can look forward to a future of collaboration, innovation, and transparency.

Let's work together to make Client-First the best it can be.