Collaborate with teammates

The Problem

Multiple users will struggle to work on the same project because they don't know who made what changes where and why.

For a New Year's hack day, I explored ideas around the theme of collaboration. What features can help users communicate and work together on the same codebase.

Let's breakdown it down

Communicate about their code in the editor.
Learn about the codebase's history.
They should be able to find out who to ask for help.
Make changes to their codebase safely.
They need to package their changes for another person to review or deploy.

Out of scope

Merge conflicts
- there might be some usability issues we need to consider later. With how users will deal with merge conflicts within Dark. But the main bottleneck holding us back from was a backend engineering concern.
Pair-programming
- maybe something down the line. Right now users will have to do it through a third party voice/video service. People have actually paired in Dark with eachother on a Twitch live stream.
Forking and sharing code
- to be addressed with our package manager.

Solving: How do I talk about my code?

Users need to be able to communicate about their code in the editor.

Constraints

Right now the only way for users to add comments in their code is with unassigned strings.

It is a workaround hack; not a language feature

Can we have simply implement comments?

Maybe make # a keyword to create a comment line or block?

But it will violate our founder's language design principle.

How can we allow for users to add comments to their code?

Reflective understanding

To communicate about a complex chunk of code in a natural language.
To temporarily disable a chunk of code during execution.
This can already be achieved with Feature Flags, which we have. And I'll talk more about those later on.

Arriving at a solution

Why don't we take page from collaborative document editing software?

Solution

When the user selects a code chunk they can add a comment to it.

They can type in a comment and collapse to hide it.

Collapsed comment will just show as a marker, and be read on click.

Solving: Who wrote this?!

When users are confused about some of the code they are reading, they should be able to find out who to ask for help.

With the popular demand for collaboration features, we have the ability to see other users who are on the same project.

But this feature only shows the user what is happening right now. What if they want to gaze into the past? How can they do that?

Space Constraints

Can we just keep the avatars there? Even if a users is not active? How can we show that information without adding more clutter?

Arriving at a solution

Borrowing from image editing software...

What about layers! As we add more features to Dark, we must give affordances for users to see different things, when performing different tasks. Not everything needs to be on the screen at all once. Layers help us reduce visual noise and addresses our running out of space problem.

By activating the change log layer, users can see who edit last.

Solving: How do I edit code in chunks?

Users need to be able to make changes to their codebase without affecting their customers immediately. And they need to package their changes for another to review or deploy.

Arriving at a solution

Feature Flags provide a method users can change and test out their code, before enabling it for all their users. But as of now, they can only flag individual chunks of code.

But new features or fixes often span across multiple parts of the codebase.

For example, let's say they add a new field to a database. They have to update POST endpoints to include the new field as input, as well as anywhere that performs SELECT * on the schema will have to handle the new column being fetched.

How can we extend feature flags to group changes together and allow someone to review all changes associated with the new feature?

Provide support for batching changes under a single feature flag.
Provide support to review the changes in a feature flag
, UI to request changes or approve changes. And also support for deploying them.

Solution

When the user select a semantically valid code chunk, they can feature flag it!

The code in the feature flag will only execute for fellow teammates who enabled this feature flag. Their customer will run on the production program.

The name field autocompletes with names of active flags. Or the user can enter a unique name to create a new feature flag.

Multiple users can make changes to the same feature flag

The feature flag is ready to go live!

Go live! (Rollout)

Rollout is the proccess in with code in the feature flag replaces existing code. After rollout is complete the flag becomes inactive

Gradual rollout
will first execute this code for a certain percent of grandusers, and slowly increasing the percent until 100%. At any point during this rollout process, if reports of errors or other problems occur, you may pause this rollout process.
Scheduled rollout
will have all 100% of grandusers use the new code at a specific date-time. ie: The hour of a week when granduser traffic is at lowest.
Immediate rollout
will have Dark deploy the new code ASAP as soon as the user clicks the button.

Putting it all together

New developer Ryan joins the team and is tasked to update the registration flow.

Feature Request: After users sign up, send them a slack invite code in their welcome email.

Ryan opens the project's space.

They see Tatianna wrote most of it.

Tatianna helps Ryan. She shows them how to create a feature flag. They pair together to create a fix.

Ryan adds more changes on top of Tatianna's feature flag

Ryan asks Adam to review the "slack integration" feature flag.

Adam gets a notification about a new feature flag, and goes to review it.

Adam rejects the feature flag, requesting additional changes to Ryan's code.

Ryan makes suggested changes, and ask Adam to look at it again.

Adam finally approves, and sets a rollout plan for midnight on Sunday.

Everyone is delighted and go out for Happy Hour!

Future Considerations

Who has permission to review?
How do we reverse or halt the deployment of a feature flag?
Will users want stricter permissions on who can amend to another's feature flag?
What should be the UI for gradual and scheduled rollout?