ddc
v0.1.0
Published
Scripts for DDC concepts
Downloads
9
Readme
Distributed Developer Collaboration
- Push to remote, any remote, a colleague's/team's/organization's. Typically https.
- A remote is responsible for authentication. This isn't purely peer-to-peer so something needs to be centralized.
- Build cluster is one remote
- A central often pushes automatically to a build cluster
- Build is a docker run, meaning we have a build process with a controlled environment, not all the setup you need for a typical build server
- Build is configured by a .-file in each module
- Builds either npm install (to sinopa etc) or docker install (to private repo usually)
- Origins may support automatically organization and repo creation, do
git remote add name url
andgit push name branch
and you're there (typically authenticated access) - Issues/tickets are branches with a branch readme (markdown)
- Frontmatter of branch readme has a Status field
- Typical branch statuses:
wip
(default),pr
/mr
,wontfix
- Readme is versioned with commits, can be the only change in a commit (such commits ideally distinguishable by )
- Merge to master typically does not affect branch status. It's a simple indexing operation to see which branches are merged.
For team communication you also need a chat. The chat should be able to set topic to a remote+repo+branch. You can start and end a topic. You can also use a topic for a single post. Chat history should be archived and retrievable per topic.
Non-technical collaboration is done through documents. Any documentation system. Any file sharing. Can be peer-to-peer through tools like Syncthing. Peer-to-peer inherently has the easiest type of access control: anyone with access can grant access to anyone else. Keep shares small!