We are undertaking an audit of the overall IPFS information ecosystem in Q1 2020. This directory within the community repo acts as a holding pen for working documents, artifacts and commentary related to this effort as we work to intentionally design our community: where people find us, how they are able to interact with us in those places, and how those interactions can become more consistent, systematic and empowering.
To further the IPFS-wide H1 2020 goal of investing in community enablement by evaluating our current information ecosystem, identifying opportunities for delivering the most value to our community, and recommending ranked next steps.
The overall framework for this audit focuses on examining the existing resources, needs and expectations, pain points, and potential action around four key pillars: channels, stakeholders, workstreams, and core goals.
Within the context of this audit, a channel is any location in which someone may be talking about IPFS upon which we may have some degree of control or influence. For example ...
- A dinner party where someone mentions IPFS probably doesn't count as a channel (unless someone in the IPFS community is at the party!)
- An IPFS-related conversation between developers on Twitter counts as a channel if we have the resources to monitor for that conversation and a playbook in place for consistent, helpful ways to nudge our way into that conversation
- The ipfs.io website is without doubt a channel: We create and maintain the website, we have total control over the messaging, etc
As part of OKRs, this audit will discover and spell out currently existing channels, including the degree to which we currently have influence/control and the amount of effort/resource (particularly monitoring) required to establish an optimal degree of effectiveness.
Within the context of this audit, a stakeholder is anyone with an interest or concern in IPFS. Because we to some degree want IPFS to be synonymous with the decentralized Web in the long-term future, and because we hope that "the decentralized Web" becomes simply "the Web", this suggests that everyone will be a stakeholder of some sort at some point — at least until the dweb becomes as ubiquitous and invisible as running water or electricity. We can't boil the ocean to that degree within this audit, but we do wish to consider a wide variety of stakeholders, for example:
- Ordinary, dweb-curious folks who just want a basic idea of why the dweb is better than the web we have now
- Non-technical (or non-dweb-technical) business users who want to know how IPFS can further their wider goals, and who have the decision-making power to encourage or discourage adoption of IPFS among the developers and other technical users in their communities/businesses
- Developers and other technical users in direct interaction with IPFS; note that this group contains a wide gamut of permutations and will need to be mapped out in more depth, some of which is outside the scope of this audit
As part of OKRs (see below), this audit will define at a basic level our major stakeholder groups, as well as the channels they may be most likely to use and their importance/value to the IPFS project in the near-, medium-, and long-term.
Within the context of this audit, a workstream is the course of action that a stakeholder takes in order to resolve their IPFS-related need. As noted above in our discussion of stakeholders, the number of workstreams existing for examination could potentially be infinite. For the sake of initial examination, we will consider workstreams that represent near-term needs, as well as others we consider to potentially be particularly critical to our success in the medium- or long-term. For example ...
- Gathering information in order to make a high-level decision about whether IPFS is a good fit. A product owner needs to determine whether IPFS is the best fit for an application's file storage needs. The product owner has a variety of specific concerns: some examples might include whether IPFS can be incorporated into the existing application without too much architectural change; whether IPFS will be sufficiently long-lived and ubiquitous a technology to be worth the effort; and whether the product can still meet its industry's security expectations if it uses IPFS. To reach a conclusion, the product owner would like to learn about analogous products that already use IPFS, and how; high-level, view primarily non-technical summaries of potential IPFS tech stacks that can be validated with the product's dev team; and scan documentation, forums, and other community resources to be assured that IPFS is here to stay.
- Resolving a specific development-related problem. An entrepreneur programmer working on a side-hustle app needs to troubleshoot an issue they encounter while hacking on IPFS on a Saturday morning. To get help quickly and accurately, they need complete, up-to-date, thorough documentation to help get them started; an active global (and thus time-distributed) community of developers potentially available to advise on specifics; and readily available forums for these discussions, including well-indexed IPFS forums, IPFS-centric IRC, and Twitter.
- Learning about the potential value of IPFS in a context outside the usual use cases. A city comptroller wants to follow up on a recommendation they are given in a city council meeting that city infrastructure maintenance records should be "put on IPFS". To learn what that actually might mean, and to answer some immediately occurring questions like "is that secure?" and "will it save money over AWS?", they need to read/watch a friendly explainer to the dweb on ipfs.io (the first Google result for "IPFS"), gain a basic understanding of the potential benefits of IPFS through FAQ content or quick topical explainers, and find some next-level-deeper information on IPFS that they can forward to their IT team.
As part of OKRs, this audit will define near-term workstreams as well as potentially critical medium- and long-term workstreams, and note both the stakeholders most likely to be involved and the channels most likely to be utilized in resolving each workstream.
Within the context of this audit, a core goal is effectively what a product or service is "about"; these are higher-level and more meta than just a product or service's application area. For example, a secure chat service might have as a core goal the desire to be free from corporate or government interference, whereas a research data tool may have as core goals big-data processing, file storage/retrieval, and data integrity. A product/project can (and usually does!) have more than one core goal. For the purposes of this audit, we examine only core goals for which IPFS is a direct enabler; for example, while that chat app might have the goal of facilitating users' social lives, that isn't so relevant to the purpose of our work. Note that the set of core goals used in this audit is based on the IPFS user/goal persona work undertaken in fall 2019.
As part of OKRs, this audit will align our earlier-identified list of core application areas with each area's core goal(s), and note the short-, medium-, and long-term weight of each, as well as IPFS' current readiness to support each application area.
The items outlined below represent the deliverables of this audit effort.
OBJECTIVE #1: Define the landscape of our existing information ecosystem.
- Result #1: We discover and spell out currently existing channels, including the degree to which we currently have influence/control, the amount of effort/resource (particularly monitoring) required to establish an optimal degree of effectiveness, and whether a channel offers a unique opportunity to proactively identify potential collaborators.
- Result #2: We define at a basic level our major stakeholder groups, as well as the channels they may be most likely to use and their importance/value to the IPFS project in the near-, medium-, and long-term.
- Result #3: We define near-term workstreams as well as potentially critical medium- and long-term workstreams, noting both the stakeholders most likely to be involved and the channels most likely to be utilized in resolving each workstream.
- Result #4: We align our earlier-identified list of application areas with each area's core goal(s), and note the short-, medium-, and long-term weight of each as well as IPFS' current readiness to support each application area.
OBJECTIVE #2: Examine and evaluate this landscape to assign weight for current and potential future effectiveness.
- Result #1: We define a set of weighting criteria to apply to the individual items in the landscape that we have identified, and apply as such.
- Result #2: We apply the weighting criteria to our previously-defined channels, stakeholders, workstreams, and core goals/application areas.
OBJECTIVE #3: Generate and rank recommendations for execution in Q2 and beyond.
- Result #1: We formulate high-level recommendations for serving or resolving the high-value items identified in Objectives #1 and #2, including the time, effort, human/technical resources, and potential org-chart impact required by each.
- Result #2: We rank these recommendations based upon the weighting logic determined in Objective #2, and follow up with human analysis and discussion on (approximately) the top 20 in order to determine best next steps based on available resources, external factors, etc.
- Result #3: For those (approximate) top 20 recommendations, we reach a decision for Q2 2020 to either take on, delegate (to a specific group/individual), or defer (to a specific time) the work required for execution. For work we take on, we create a high-level workplan suitable for transfer into Q2 OKRs.
- End January: Q1 OKRs defined and agreed upon; research initiated.
- End February: Initial high-level research complete and visible in rough form in the "Artifacts" list below.
- End March: Research refined and consolidated into ranked high-level recommendations; decisions on (approximate) top 20 recommendations reached; for work to be undertaken in Q2 by core collabs and community team, high-level workplan created; for work to be delegated, recommendations clearly communicated to delegates.
A note on triage: As this is research and exploratory work, it may be pre-empted due to tactical urgencies or other unforeseen circumstances. If this is the case, our approach will be to continue to reach the milestones stated above, but at a lower level of granularity. With this in mind, our approach to this audit as a whole will be iterative — to start at the broadest level, and continue to refine to the degree time permits. Fortunately, no triage was needed on this effort.
- Channel inventory/weighting (Airtable sheet)
- Information on channels is captured; channels are weighted and ready to be considered in recommendation scoring
- Stakeholder inventory/weighting (Airtable sheet)
- Information on stakeholders is captured; stakeholders are weighted and ready to be considered in recommendation scoring
- Workstream inventory/weighting (Airtable sheet)
- Information on workstreams is captured; workstreams are weighted and ready to be considered in recommendation scoring
- Application areas and core goal inventory/weighting (Airtable sheet)
- Aligns prior art in application areas with prior art in goal-based personae
- Information is captured; app areas are weighted and ready to be considered in recommendation scoring
- Audit recommendations and decisions
- All audit recommendations, ranked with decisions (Airtable sheet)
- Subset: Recommendations chosen for action in Q2/Q3 (Airtable sheet)
- Longer-form recommendation descriptions/notes (Canny board)
- Note: This master recommendations sheet is intended for use going forward as a backlog and voting sheet for future non-core-development IPFS efforts; we intend to revisit quarterly for evaluation and re-prioritization
- Q2 2020 action plans
- GitHub issues (in
docsrepo) for recommendations delegated to IPFS docs team - GitHub issues (in
ipfs-primer,awesome-ipfs,team-mgmt, andcommunityrepos) for recommendations taken on by ecosystem team - Working document (Google doc) for defining and formalizing an approach to improving the IPFS "tool family" (Companion, WebUI, and Desktop)
- GitHub issues (in
- IPFS preliminary landscape segmentation and use cases (Google Slides deck)
- Developer use case ecosystem audit by @andrew:
- IPFS ecosystem research notes (Google doc)
- IPFS ecosystem collaborators survey (Google doc)
- Application area report (Airtable; password required)
This project is being managed by @jessicaschilling; please contact her with questions or feedback.
Source photo for banner: Tabitha Mort/Pexels