Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Buddy list #22

Closed
simurai opened this issue Jul 13, 2017 · 2 comments
Closed

Buddy list #22

simurai opened this issue Jul 13, 2017 · 2 comments

Comments

@simurai
Copy link
Contributor

simurai commented Jul 13, 2017

This issue continues from #18 (comment) and is for brainstorming how the buddy list could look and work.

@simurai
Copy link
Contributor Author

simurai commented Jul 13, 2017

Here a "Team" panel (dock item):

screen shot 2017-07-13 at 1 45 50 pm

  1. At the top you can switch between orgs you belong. Some orgs might be very large, so you can further limit it to a certain team only. Then whenever you want to share a portal as host, you can enable it with the toggle switch. At this point team members can see that you started to host a portal and can join. This is nice because you don't really have to actively invite somebody if you regularly pair. You can just start sharing and start coding. Then whenever the other person is ready, she will join you.
  2. Next sessions that you joined as a guest are shown. You can leave at any time.
  3. Then sessions that you haven't joined are shown. Allowing you to jump in.
  4. Here somebody is hosting, but without any guest present.

screen shot 2017-07-13 at 1 46 21 pm

  1. If you're hosting a portal and want to "actively" invite somebody, you can click the ➕ button. Now all team members are shown. Clicking the invite button will prompt a modal where the invitation can be accepted or declined. People that are offline are shown at the end of the list, but can't get invited.
  2. At the bottom non-members can get invited. Either by their GitHub @user-name, or by copy and pasting (into Slack or so) the portal ID.

Inviting non-members might raise some privacy/security concerns. Especially if it's possible to join with an ID only, where guests have no name and avatar. Maybe to prevent accidental leaks, should it somehow be tied to who has access to the project/repo? For example if I share with the atom/maintainers team, and then start editing this real-time project, should only those team members that also have access to this repo see my portal?


I was also wondering if it would be helpful to know what a session is about. Only seeing who joined, doesn't reveal much. So there could be an input where you can enter your current "status". Then people know if it's something they're interested.

screen shot 2017-07-13 at 1 46 43 pm

Or you can explicitly "ask for help" and hopefully somebody will join you. It will also show the project name and the branch you're currently on, to give further context. And as seen in the last example "settings-view@0.251.1", if you don't manually enter a status, it will just show your last commit message automatically.

Of course this can be added in a later milestone, or is more part of the "live branch" concept.

@jasonrudolph
Copy link
Contributor

We're going to use the feedback from the beta release to determine the priority of future enhancements. With that in mind, I'm going to close this issue for now. Depending on the feedback from the beta release, we might re-open this issue or build on these ideas in a future issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants