Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gitcoin Tribes v1 Designs #5467

Open
frankchen07 opened this issue Nov 7, 2019 · 11 comments

Comments

@frankchen07
Copy link
Contributor

@frankchen07 frankchen07 commented Nov 7, 2019

User Story

Gitcoin Tribes v1 Designs

Why Is this Needed

As we improve on our hackathon offerings, Gitcoin Tribes is the offering that allows sponsor / hacker relationships to continue.

Description / Positioning Statement

Gitcoin Tribes positioning statement:

  1. Gitcoin Tribes offers a two-way broadcast for highly engaged hackers and funders to continue relationships and do high-leverage work, together.

  2. Gitcoin Tribes builds highly engaged communities to help hackers and projects grow together.

Problems (Sponsor-side)

As an early stage Web 3 company, my two focuses are 1) building tech and 2) building community. Building and maintaining community is hard, especially in a way which is value additive to the community over long time horizons.

In order to build tech, the sponsor has to have a strong community. This means several problems that the sponsor is faced with, which we'll be testing with design and initial mock builds. You'll notice that the problems are very relationship focused.

  1. How can I find great additional hackers to work on my projects beyond the hackathon?

  2. How can I engage and retain great workers to continually improve my project?

  3. How can I manage my open source tribe?

  4. Overall, how can I maximize and make best use of my open source tribe?

Current Designs

  1. Tribes view from the organizations page as well as the dashboard. There are updated tabs showing tribe information. This addresses point 3 about how sponsors will manage their open source tribe, putting it front and center on management tools in the Gitcoin app.

Untitled

Untitled (1)

Untitled (2)

  1. The design for the "invite user to tribe" from the user directory addresses problem number one, where sponsors can find additional hackers to invite to their tribe after a fuller vetting process. It opens the gateway for this to happen.

Untitled (4)

  1. The design for "inviting your tribe (some or all) on the fund issue page" partially addresses problem number 2, which is engaging and retaining your community.

Untitled (3)

This is obviously a v1, which is a beginning to opening the eyes of the sponsor to what is possible. As a start, we want engineering's thoughts on this, as well as the sponsor's thoughts on what additional "pro" features they expect to address these problems. More ideas are expected for problem number 2 - how to retain and engage their tribe.

There may also be additional solutions on management, as well as the "vetting" process for Tribes, but the v1 nicely packages up and connects a variety of Gitcoin components that we already have.

Next Steps

  1. feedback from Gitcoin internal engineering
  2. prepare designs or build for sponsor interviews & prep interview guide
  3. v1 feedback
  4. iterate & buidl more
@danlipert

This comment has been minimized.

Copy link
Collaborator

@danlipert danlipert commented Nov 11, 2019

From a backend standpoint I think this is pretty simple to implement - from a frontend/design standpoint I'd like to see the "invite to tribe" functionality have some more consistency. Within this ticket alone I think there are 3 different designs for inviting someone to a tribe. But otherwise I think its good - one additional note is that I think the "Email Tribe" functionality is somewhat dangerous in terms of potential for spamming and security issues - might be better replaced by something involving our upcoming internal chat tool.

@frankchen07 frankchen07 moved this from To do to In progress in Robot Board Nov 11, 2019
@thelostone-mc

This comment has been minimized.

Copy link
Member

@thelostone-mc thelostone-mc commented Nov 11, 2019

Email Tribe

@frankchen07 + @vs77bb
not to super keen on that functionality as it still does feel spammy.
Would it make more sense to simply show up the bounties posted by the tribe to it's memebers
Kinda like a bounty feed from the tribe

If i follow Gitcoin + Metamask -> All the open bounties in those would pop up under my dashboard under the tribes section

Agree with @danlipert on the "invite to tribe" functionality have some more consistency.

================

@willsputra would you happen to have the email layout designed too for

  • invite user (sent to user)
  • user requesting to join ( sent to tribe owner )
  • user rejecting invite (sent to tribe owner + user )
  • user accepting invite (sent to tribe owner + user )
@vs77bb

This comment has been minimized.

Copy link
Contributor

@vs77bb vs77bb commented Nov 12, 2019

@danlipert @thelostone-mc agree on potentially holding on 'E-mail Tribe' as a standalone thing... think its useful in the 'Invite Tribe' context, maybe less so as just a standalone email.

Pinged @willsputra on getting some of the "Invite to Tribe" functionality questions addressed...

What are Engineers thoughts on the usefulness of this new view? Does it strike you as helping the UX of a funder / of devs? Something missing? Curious on those things as well past the implementation... want to build a simple v1, but also one we're excited about!

@danlipert

This comment has been minimized.

Copy link
Collaborator

@danlipert danlipert commented Nov 12, 2019

@vs77bb seems very useful to me - it will be very effective for an org to focus on growing their tribe and once they do they will pretty much live here

@willsputra

This comment has been minimized.

Copy link
Collaborator

@willsputra willsputra commented Nov 12, 2019

@danlipert @thelostone-mc @vs77bb thanks for the feedback! yes I agree the "Invite to Tribe" function could be more visually consistent - will work on that today.

Email Tribe

noted on putting a hold on this for now. originally thought of this as a way for funders to announce cool new stuff outside the context of bounties (e.g. announcing new features, new version of contract etc.) as part of maintaining relationship with contributors, but yeah email could be kinda spammy. happy to brainstorm ideas here too!

@willsputra would you happen to have the email layout designed too for
invite user (sent to user)
user requesting to join ( sent to tribe owner )
user rejecting invite (sent to tribe owner + user )
user accepting invite (sent to tribe owner + user )

not yet but will work on a couple of those first so we can also show it to funders for feedback.

@ceresstation

This comment has been minimized.

Copy link
Member

@ceresstation ceresstation commented Nov 12, 2019

So I'm still a bit concerned that this design allows you to interact with individual contributors but not to view your tribe and their interactions with your project on a holistic dashboard. Is this latter more integrated view (e.g. with an easy way to ask a Tribe member to become a project owner, a way to assign Tribe members to individual tasks, and so on) in the works?

@willsputra

This comment has been minimized.

Copy link
Collaborator

@willsputra willsputra commented Nov 12, 2019

making the invite actions more consistent:
invite

@frankchen07 frankchen07 moved this from November / Sprint 22 to November / Sprint 23 in Gitcoin Roadmap Nov 12, 2019
@owocki

This comment has been minimized.

Copy link
Member

@owocki owocki commented Nov 12, 2019

my thots below:

add to 'problems' - how do i engage new people after i've done one hackathon and reached the local maxima of the size of my tribe?

current designs

  • in addition to existing designs... i'd love to see wireframes of all the stuff thats on the feature list for tribes all together (pitch a sponsor, keep up with my tribe, take a hackathon user and put them on a grant, what else??? ).. espeically important will be the navigation as that'll be how users get from site to site
  • one design i'd particularly like to see is tribe stats - how big is my tribe over time? if were successful, people will care a lot about optimizing this number - just like how marketers are obsessed with increasing their twitter/fb follow counts.

other questions

  • are we sure we want to have 'join tribe' as a double opt in thing? why not just make it more like twitters follow button where anyone can join a tribe? will massively simplify the UX. for a v2 -- maybe if there is some reason you need a "tribe owners" consent to act on behalf of the tribe we can have a smaller circle on 'blessed tribe members' that can perform said things
  • it'd be good to consider some of this stuff in the context of cerebro ( https://gist.github.com/owocki/16e02b836f20fd84173e9dc14d96d973 ) launching around the same time

Email Tribe

Personally I'd like to see more people looking at the activity feed on gitcoin.. if there were more eyes on that, that'd be a great place to broadcast info to your tribe members. kind of like the newsfeed on facebook

maybe if we HAVE to go with email tribe.. we can roll up all the invites/notifications/messages people get and put them in the weekly roundup..

@connoroday

This comment has been minimized.

Copy link
Member

@connoroday connoroday commented Nov 12, 2019

I agree with some of the thoughts above, regarding the email feature potentially being spammy. Perhaps we only allow 1 email per month to the entire tribe, to make sure the messages are meaningful? Or rather than an email feature, a simple bulletin board that the sponsor can post to where hackers check in for updates.

I'm also not sure we need to "gatekeep" the tribe so much, with the vetting process described. Companies want to grow their communities as much as possible, I don't see the value in denying hackers access, rather maybe we make it easier for anyone to join a tribe with a "premier" group of users who have completed a certain amount of bounties, or have been vetted. I suppose this is the goal of the "Follow" button, anyone can follow a company they like. But if they get denied from joining the tribe, I could see that turning individuals off to a company.

This might just be nitpicking syntax, but what if instead of "Follow", we call that "Join Tribe", and then instead of "Request to Join Tribe" the higher access could be "Request to be Tribe Chief" or "Premier Tribe Member", etc. It sounds better for community building to say "We have 500 tribe members with 15 chiefs" than "We have 15 tribe members with 500 followers" in my opinion.

On another note, one of the first things you say is "As an early stage Web 3 company...". I think we should expand this thinking a bit. While small blockchain companies are definitely a target customer, the Microsofts and Amazons of the world are also great candidates for Tribes. There is value for larger enterprises to build out a blockchain developer community, and they have the deep pockets that early startups may not. We should be thinking about the features of tribes in context of these larger organizations as well.

Finally, this user story seems wholly focused on hackathons, which is great, but I think standard bounties will also play a big part. Part of retaining and engaging their tribe members will likely be non-hackathon bounties. Will a Tribes subscription give companies a discount on the 10% bounty fee? This may be out of scope of this v1 design, but we should consider the full suite of features for Tribes subscribers, from hackathons to normal bounties, recruitment tools to hire devs full time, access to better targeting tools (see my feedback on Kevin's Cerebro spec below) etc.
https://gist.github.com/owocki/16e02b836f20fd84173e9dc14d96d973

@frankchen07

This comment has been minimized.

Copy link
Contributor Author

@frankchen07 frankchen07 commented Nov 13, 2019

just to organize some of these thoughts for you @willsputra, there's alot of great feedback above

  1. invite to tribe consistency - I'd also add, let's make sure in a UX fashion, the actions that the sponsor can take in each location makes sense. The designs above tell me the dashboard is where inbound items are for my tribe and has pretty much all the actions necessary to completely manage my tribe. The organization view also has some ability to invite to bounty or invite to tribe. Action item: for what we have now, @willsputra let's make sure the requisite CTAs on each page makes sense.

  2. great points above about the email Tribe, and potentially replacing this with the chat function. I wouldn't say it would just be a button that says "chat" but some more elegant way of leading to the ability to open a chat function. Action item: @willsputra is there a way to generalize a design that lets the sponsor know it leads to some form of communication? That will segue into how we can ask them how they like to communicate and what works for them. Will leave it up to you if you want to make 2 designs so we can cross compare - I think the design should be more open ended so we can ask them on their preferences on communication.

  3. it sounds like the exclusivity of joining a tribe is up for debate. Some of us think the value comes from really vetting great members and it's a "special" thing to join a tribe, other think that it should be looser and free-er. This will definitely be a point that we want to ask sponsors in our interviews to see where they land on this. Action item: make sure we hit this point in our interviews.

wireframes of all the stuff thats on the feature list for tribes all together (pitch a sponsor, keep up with my tribe, take a hackathon user and put them on a grant, what else??? ).. especially important will be the navigation as that'll be how users get from site to site

  1. I want to avoid alot of feature creep until we have confirmations for some of the assumptions on some of these features. Some of them are also on the contributor side. For the sake of faster, lighter testing, I can try and touch on as many of these points in interviews. Not saying they're not good ideas, since I think having these would make sense from the flow of working with a Tribe member, but b/c it makes sense to us doesn't mean it makes sense to them.

  2. cerebro we can definitely add in as a tools that are helpful to grow a tribe, I think it can make it's way into the first build, if even if it's just a clickable concept. If that fails, we still have the user directory. Action: cerebro milestone I (as of 2019-11-13) is generally complete (there's no front-end to it yet) but it's essentially a ML model that surfaces matches of contributors. Easiest and fastest way would be to just say that the user directory does this, and gauge reactions.

This might just be nitpicking syntax, but what if instead of "Follow", we call that "Join Tribe", and then instead of "Request to Join Tribe" the higher access could be "Request to be Tribe Chief" or "Premier Tribe Member", etc. It sounds better for community building to say "We have 500 tribe members with 15 chiefs" than "We have 15 tribe members with 500 followers" in my opinion.

  1. This could be an interesting branding thing. @willsputra, do you think this muddies the "understanding" of a what a Tribe is? My caution is to make it as easy as possible first to have them understand what a Tribe is, since we don't want to test way too many concepts at once.

  2. Agree with Scott's comment and my own original comment on thinking the Tribes functionality is a holistic place where work and conversations can take place too, but this remains unproven, and will be a question we want to probe sponsors about via the 1st set of interviews. Action item: make sure we hit this point in our interviews.

but we should consider the full suite of features for Tribes subscribers, from hackathons to normal bounties, recruitment tools to hire devs full time, access to better targeting tools (see my feedback on Kevin's Cerebro spec below) etc.

  1. totally agree, similar to point 7, we'll have to get there iteratively as we get more confirmation from sponsors as to what they want.

the Microsofts and Amazons of the world are also great candidates for Tribes

  1. would this be a completely different workstream? The needs here might be different, and so during interviews we would be pursuing a slightly different customer. No action item here yet, but eventually we'll get there.
@frankchen07 frankchen07 moved this from In progress to PR Review in Robot Board Nov 13, 2019
@vs77bb

This comment has been minimized.

Copy link
Contributor

@vs77bb vs77bb commented Nov 15, 2019

Have compiled lots of the discussion here into topics for convo in our call today. Here they are, for reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.