This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Delegate

What is a Mission Driven Stakepool

A Mission Driven stake pool is connected to a project or team that itself is mission driven. The Stakepool has soul, so to speak.

Well what exactly is mission driven?

We refer to something as mission driven, if the focus of the project is on a clearly defined purpose. Usually that purpose involves open source (or commons) contributions, creation of closed loops systems, ecological sustainability or regeneration and regenerative practices.

Some Alchemy.

What happens if you mix two things together? You receive a third new thing. Hence combining the mission driven aspect with stake pool operation leaves us with a novel kind of entity, that is able to self sufficiently and organically grow & nurture community around a cause. We can go on further and mix this entity with again something new, like DripDropz and voila never before seen or felt possibilities emerge!

Take a ride with us.

1 - Overview

Here’s where your user finds out if your project is for them.

This is a placeholder page that shows you how to use this template site.

The Overview is where your users find out about your project. Depending on the size of your docset, you can have a separate overview page (like this one) or put your overview contents in the Documentation landing page (like in the Docsy User Guide).

Try answering these questions for your user in this page:

What is it?

Introduce your project, including what it does or lets you do, why you would use it, and its primary goal (and how it achieves it). This should be similar to your README description, though you can go into a little more detail here if you want.

Why do I want it?

Help your user know if your project will help them. Useful information can include:

  • What is it good for?: What types of problems does your project solve? What are the benefits of using it?

  • What is it not good for?: For example, point out situations that might intuitively seem suited for your project, but aren’t for some reason. Also mention known limitations, scaling issues, or anything else that might let your users know if the project is not for them.

  • What is it not yet good for?: Highlight any useful features that are coming soon.

Where should I go next?

Give your users next steps from the Overview. For example:

2 - Concepts

What does your user need to understand about your project in order to use it - or potentially contribute to it?

This is a placeholder page that shows you how to use this template site.

For many projects, users may not need much information beyond the information in the Overview, so this section is optional. However if there are areas where your users will need a more detailed understanding of a given term or feature in order to do anything useful with your project (or to not make mistakes when using it) put that information in this section. For example, you may want to add some conceptual pages if you have a large project with many components and a complex architecture.

Remember to focus on what the user needs to know, not just what you think is interesting about your project! If they don’t need to understand your original design decisions to use or contribute to the project, don’t put them in, or include your design docs in your repo and link to them. Similarly, most users will probably need to know more about how features work when in use rather than how they are implemented. Consider a separate architecture page for more detailed implementation and system design information that potential project contributors can consult.