Overview#

This document supports the decision on the Network Project Manager / Gestionnaire de projets réseau posting at Abundant Intelligences (Concordia / AbTeC / Indigenous Futures Research Centre), tracked as episode 347 and miadisabelle/Etuaptmumk-RSM#265. It addresses two questions directly relevant to the role: which tools best manage decentralized, multi-site research networks, and how to balance technical software development with community coordination work. The goal is a working reference that can inform the cover letter, the exploratory message to the lab manager, and the eventual day-to-day practice if the position is taken.

What "decentralized research network" tooling actually means here#

The posting's "network" is organizational, not infrastructural: three cross-network research initiatives connecting researchers, community partners, Indigenous Knowledge holders, Indigenous-led Research Pods, project leads, and a Research Leadership Group across institutions, cultures, regions, and time zones. Tooling choices for this kind of network differ from tooling for a single-site lab because the binding constraint is not compute or bandwidth but trust, consent, and asynchronous alignment across groups that do not share an institutional home. Academic literature on decentralized research data management frames this as a deliberate trade-off: decentralized systems avoid single points of control and failure but require more explicit protocols for how information moves and who can act on it. A useful comparison case is DARIAH-EU, a distributed digital-humanities infrastructure that does not centralize services but instead lets national nodes contribute what they already do well, coordinated through open working groups built around a methodological focus. That is a closer analogue to a Research-Pods model than any single SaaS product.[^1][^2]

Tool categories and where each fits#

No single platform covers coordination, documentation, and Indigenous data governance simultaneously, so the practical answer is a small, deliberately chosen stack rather than one "best" tool.

GitHub itself is increasingly documented as a legitimate research-coordination tool beyond software, used by wet-lab and field-science teams to track issues, log decisions, and manage versioned protocols with an organization-level account so continuity survives staff turnover. That maps well onto the user's existing GitHub-based workflow (inquiry-weave, Etuaptmumk-RSM) and suggests the medicine-wheel and distributed-agent work already constitutes relevant infrastructure experience, described in the register the prior inquiry proposed: relational, community-informed software and knowledge-architecture work.[^11][^12]

The Indigenous data governance layer is not optional#

Because the network explicitly includes Indigenous-led Research Pods and Knowledge holders, tool selection is inseparable from governance. The OCAP principles (Ownership, Control, Access, Possession), developed by the First Nations Information Governance Centre, assert that First Nations communities retain collective ownership of and control over data and knowledge concerning them, including decisions on collection, storage, use, and destruction. The complementary CARE principles (Collective benefit, Authority to control, Responsibility, Ethics) extend this to the design of the data ecosystem itself, not just individual datasets. In practice this means:[^9][^10][^13]

• Any shared repository or wiki needs configurable, community-controlled access tiers, not just "public" or "private."
• Whichever project tracker is chosen should support per-Pod visibility settings (OSF's contributor permission levels are one working example).[^14]
• Documentation of data flows and destruction/retention terms belongs in the same system as the project plan, not as a separate afterthought.
• A Research Community Manager framing—drawn from recent work on professionalizing this exact role in interdisciplinary projects—positions the coordinator as responsible for reproducibility norms, fair recognition, and stakeholder engagement, which aligns closely with what this posting asks for.[^15]

This is the area where the position could either become "keep an existing structure running" or genuinely "improve the network's methods and tools," the distinction the prior inquiry flagged as the decisive question. Asking directly whether the role has authority to shape data-governance tooling, not just administer meetings, is the single highest-value clarifying question before applying.

Coordination model: community of practice over command structure#

Distributed research networks with no single reporting line function better as communities of practice than as conventional hierarchies. The concept, originating with Wenger, describes groups that share a concern or endeavor and improve their practice through regular interaction rather than top-down direction. The European Commission's Communities of Practice Playbook operationalizes this into eight success factors: vision, governance, leadership, convening, collaboration, community management, user experience, and measurement. For a Network Project Manager, this translates into concrete practice:[^16][^17][^18]

• Convening regularly scheduled, well-facilitated sessions with published multi-timezone times, rotated to share the burden of inconvenient hours.[^8]
• Maintaining a single source of truth for decisions and open questions, so asynchronous participants are not structurally disadvantaged.[^8]
• Treating documentation as an equal deliverable to meetings — every session converts into durable artifacts (tasks, updated protocols, revised timelines).

Balancing technical development with community coordination#

The tension between hands-on technical work and relational, facilitative labor is well documented in project-management and leadership research, and the resolution pattern is consistent across sources: deliberate time allocation plus a shift in leadership model, not an attempt to do both simultaneously at full intensity.

Servant leadership as the operating model. Project managers in cross-functional, low-formal-authority environments — which describes this role, since the Network PM does not appear to supervise Pod members directly — rely on servant leadership: enabling team success, removing blockers, and building trust rather than issuing directives. This model explicitly complements technical credibility rather than replacing it; credibility earned through real technical contribution increases the coordinator's influence when they are not facilitating a meeting.[^19][^20][^21]

Time-boxing, not multitasking. Research on technical leads moving into management repeatedly recommends structural separation of modes: reserving defined blocks for deep technical work and separate blocks for meetings, mentoring, and stakeholder management, rather than interleaving the two within the same hours. Applied to this role, that could mean protecting specific days or mornings for workflow and tooling development (the "improve the network's methods and tools" side of the tension) and using other blocks for the facilitation cycle: prepare a session, run it, capture decisions, convert them to tasks, track progress, return with a clearer shared map.[^22][^23]

Delegation and documentation as force multipliers. Both technical-leadership and PM literature converge on delegating technical tasks to capable team members and treating documentation as the connective tissue that lets a network run without the coordinator present at every point. This is precisely the same instinct behind Git-based documentation and OSF's versioned wiki: durable, reviewable records reduce the volume of synchronous relational labor required to keep a distributed team aligned.[^24][^23][^7][^22]

Framing technical work as evidence, not distraction. The distributed-agent and medicine-wheel software work should not be read as competing with the coordination role; it is evidence of systems thinking, workflow design, and knowledge-provenance practice, exactly the skill set community-of-practice and research-community-manager roles need. The risk to manage is time allocation, not relevance: without protected blocks, coordination and stakeholder work expands to fill all available time, since PMs in comparable roles report spending up to roughly 90 percent of their time communicating.[^15][^19]

A minimal recommended stack for this specific role#

Given the network's composition (institutions, Indigenous-led Pods, external AI-lab partners, GitHub-based inquiry-weave workflow already in use), a pragmatic combination is:

• GitHub (organization-level, already familiar) for issue tracking, versioned protocols, and technical documentation reviewed like code.[^12][^7]
• OSF as the shared research-lifecycle hub connecting file storage, contributor permissions, and external tools (Dropbox, GitHub, Google Drive) that different Pods already use, avoiding a forced migration to one proprietary system.[^5][^25]
• Slack, used with async-first norms (recorded sessions, published multi-timezone meeting times, decisions logged outside the chat stream) as the day-to-day coordination layer.[^8]
• An explicit OCAP/CARE-aligned access policy layered across all of the above, treated as a governance artifact maintained alongside the technical stack rather than a compliance checkbox.[^10][^9]

Open questions to resolve before applying#

Consistent with the linked issue's structural tension, three unknowns determine whether this stack recommendation is actionable in practice: who the direct supervisor is, what proportion of the role is administrative versus developmental, and whether the coordinator has standing authority to change digital workflows and tools rather than operate within a fixed structure. The tooling and coordination models above are strongest arguments for the position if the answer to that third question is yes.

---

References#

1. In defense of decentralized research data management - Abstract Decentralized research data management (dRDM) systems handle digital research objects acros...

2. DARIAH-EU: Digital Humanities Infrastructure - CASRAI - DARIAH-EU explained: ERIC status, governance, member countries, funding model, and key services for ...

3. OpenProject is the leading open source project ... - GitHub - OpenProject is the leading open source project management software for product, project and portfoli...

4. Open Source Project Management Software - Plane - Open source project management with work items, cycles, wiki, and views. Run on Docker/K8s, own your...

5. What is Open Science Framework? OSF features and… — CASRAI - Open Science Framework (OSF) is an open-source project management platform that helps researchers co...

6. Chapter 2 The Open Science Framework - GitHub Pages -

   The present book aims to describe programming good practices and introduce common tools used in s...

7. Knowledge Management for Dev Teams 2026: 4 Tools ... - This is a comparison of four knowledge-management approaches — Confluence, Notion, GitHub Wiki, and ...

8. Working with Distributed Teams | Async Collaboration - Collaborate across time zones with async-first practices. GitScrum provides documentation and visibi...

9. 1

10. CARE Principles for Indigenous Data Governance - CASRAI - Published in 2019 by GIDA, the CARE Principles sit alongside FAIR for Indigenous data. Collective be...

11. GitHub enables collaborative and reproducible laboratory research - GitHub, a platform widely used in software development, offers a robust framework for documenting al...

12. Getting Started with Git and GitHub for Research Laboratories ...

13. The First Nations Principles of Ownership, Control, Access ... - OCAP® provides a framework for asserting jurisdiction over First Nations data and represents a criti...

14. Open Science Framework (OSF) - PMC - NIH

15. Professionalising Community Management Roles in Interdisciplinary Research Projects - ...referred to here as the Research Community Managers (RCM). Drawing insights and examples from res...

16. Exploring the evidence base for Communities of Practice in health research and translation: a scoping review - ...PMCID: PMC10278351  PMID: 37337214

Abstract#

Background#

The translation of research into...

17. The Communities of Practice Playbook | Methodology - The Communities of Practice Playbook

18. JRC Publications - The Communities of Practice Playbook - Communities of practice can bring groups with different knowledge perspectives together and can stre...

19. Essential Project Manager Skills: 7 Key Competencies - Boundev - Master the 7 essential project manager skills: communication, leadership, risk management, stakehold...

20. Project Servant Leadership: Enabling Team Performance - Project Servant Leadership: Enabling Team Performance PMBOK v8 Definition Servant leadership is the ...

21. 5. Credibility And Expertise - Leading without formal authority is essential in technical roles. This article explores how to influ...

22. Balancing Technical Expertise with People Management - Substack - The best leaders are those most interested in surrounding themselves with assistants and associates ...

23. What Strategies Help Balance Technical Expertise and ... - To balance technical expertise and people management, prioritize continuous learning in both areas, ...

24. Welcome to OSF Projects - The OSF is undergoing a Project Transition for more information on how this may affect you or your O...

25. Connecting Your Research Tools on the Open Science ... - What are Add-Ons in the OSF? Add-ons are outside tools and platforms researchers already use for the...