Distinguishing Between Brigade "Sanctioned"/"Official" Projects and other Projects

Projects
1

Hello Brigade Network!

I am on the Core Team of a new brigade in Milwaukee, and we are trying to make decisions on how projects either receive extra resource support from or become owned/managed by the core team vs those that simply have dedicated time and space at a hack night. I was wondering if other core teams make these distinctions and how.

Some things we have been considering with respect to this idea are:

  1. The political nature of a project, and our pledge to be non-partisan
  2. Our responsibility to serve the community, this cannot be completely apolitical at all times
  3. Resource constraints
  4. Making sure core-team commitments are manageable and sustainable (as far as how many projects we are providing extra support or mgmt support to)

Any advice or thoughts would be very helpful!

Thank you very much,

Andrew

2

Hey @Andrewyaz, welcome to Discourse!

You’re posting in the right place-- this is a common topic in the Brigade Network.

The current Brigade policies around this have been indexed in this Discourse topic:

There is probably quite a bit more discussion to have though, as those resources probably don’t directly answer all of your questions!

3

I touch on this topic a bit in the Civic Cloud proposal:

I think an important dimension to a project becoming an “official” brigade project should be ensuring a complete technical handoff of the deployment process and accounts. That means taking projects to a point where the whole original dev team can cancel an their credit cards a disappear without the project’s online components going down, and that a new volunteer could show up and open a PR and the brigade can ship that without the original team

The norm these days is brigades can’t and don’t keep anything online after the original devs disengage, and that severely hinders our reputations in our communities and the good faith available to future projects

1 Like
4

Great. Thank you for directing me to all that great institutional knowledge.i will definitely go through the materials and post follow up questions in the thread

5

Code for BTV, like many brigades, has been struggling with this for years. Right now the struggle has become “are we over-doing it?” There is a lot to be said for clear process, and careful thought going into a brigade making a public commitment to a project. But at the same time, the more significant the process and gate-keeping that is going on with projects, the less nimble we become, and the less we are able to quickly harness volunteer excitement.

For example in thinking about resource constraints - especially if you consider your volunteers to be project resources… while it is extremely easy to think of the volunteers in the same way that you think of employees working on a project, they are not employees and are not driven by the same needs or desires as those working in “a job.” So … and this is a current discussion in our brigade … can we reasonably consider the volunteers, broadly, as a resource to manage? Or is the reality the opposite … perhaps the core team is the resource that the volunteer project teams are using?

In terms of politics… Brigades, and CfA state we are non-partisan, non-neutral. We fight for issues, but not for candidates. In such a polarized country, it is easy to think of people as being all for or all against your ideals, but if we step back to just focusing on particular issues, we may find it easier to support political movement without broadly or specifically supporting a candidate. You always need to be careful with politics of course… and I won’t pretend to be some kind of person that even knows more than you… I’m just saying how our brigade thinks about it.

Our core team members are involved in specific projects, and our project delivery lead presently has his thumb in all the project pies, but we don’t really think of the “leadership” team as being required to have direct involvement in building or developing a project. Rather, presently, we have so few formal brigade projects that we can listen to them for what their needs are, and provide specific support as requested.

I think I’ve read that some brigades effectively wait for a project to reach a certain point, and then adopt it. That may be a good model. We don’t do that. We determine before a project starts if it makes sense (in terms of ideals and goals, likelihood of failure, achievability, needs), and then if it gets our stamp, we work to put human resources to it… a PMP, a tech lead, and whatever other necessary volunteers it might need (programmers, UX / design, QA & testing, promotion). Just as importantly, we do not take on a project, currently, without the project having a “client” … an individual who represents the client organization, who can be involved in the development, and who can provide the domain knowledge that our volunteers won’t have. The client is also the final recipient of the project work… because our brigade does not want to host or run any sites or services or tools… we want to build and hand-off.

I’m not sure if this muddies the waters, or not. But at least this is what we do right now. I started a Slack discussion in the #small-brigades channel today on the topic of how important gate-keeping is… as that is our current concern. We have trouble finding the volunteer developers, and are not sure if it is because we are too discriminating about projects such that we squash the sort of dynamic volunteer energy that often starts new projects?

2 Likes
6

I think this is a really key point, and that no we can’t think of volunteers as “resources” we can manage and impose requirements on. On the flip side though I think it’s important to think about our duty to people who volunteer their time. Once a project reaches a certain point, is it fair to let them get up and present the effort as owned by the community while recruiting volunteers while in practice one person still holds all the keys and the every volunteer’s work will effectively be “erased” when they have to step back?

My sense is that we neither want to gatekeep out projects or exclude them from being considered “brigade projects” until they reach a certain point. Rather, what if the funnel was wide open at the bottom for folks to be creative and there was a “carrot” with intrinsic value for attaining some higher-level designation like “official project”. The only carrot I’ve come up with in that frame is relief from having to pay for / manage hosting/maintenance. I think it’s a good one because we’ve already seen that people will jump through hoops using low-infrastructure tools to avoid maintenance obligations, and it also directly fulfills the implicit promise we make to volunteers who show up and give their time that the project’s they’re contributing to belong to the community.

1 Like
7

I come down in two ways when it comes to the ‘official project’ issue.

Common scenario: Newish member in Open Mos Eisley forks an existing project… let’s say oh, I dunno, Luke Skywalker and Adopt-a-hydrant. Newish member starts working on it and finds that it really…doesn’t work the way they thought it did. (It takes a lot of groundwork by the city to really make it work). Technically speaking, that counts as a Brigade project and (until recently) we’d track that in the Brigade project tracker. The project itself is not good and not really useful.

AND THAT’S FINNNEEEEEE - Now, young Skywalker has taken his first steps into a larger world. Tinkering doesn’t produce great project, but it’s a a skillbuilder that eventually goes on to produce civic tech masters. You’re not gonna slay a rancor on your first day.

People building is a critical part of the Brigade and even if they’re not producing anything of value - it’s still serving the mission of the Brigades. We don’t get Brigade people placed in high levels of government without having opportunities for tinkering and gaining experience.

The second place that I come down on the issue is that really big projects require a level of resource projection that people might find hard to just walk into at random…though you can intentionally recruit for a project. To continue the Star Wars references, if you’re going to take down the Death Star you need a lot of resources. That includes an overall plan, somebody recruiting team members, people gathering intel, and people running point on the mission. For these sorts of things, I’d recommend a Brigade talk about this as a group and get consensus within the group to commit the resources required. Not every project needs to go through the process, but when you’re committing a lot of resources you need the consensus.

Chi Hack Night has two kinds of breakout groups - learning and working. For people tinkering or wanting to learn, we point them to the learning groups. The working groups are much more focused on projects. This helps with the tension between people wanting to ‘do work’ vs coming to learn. (Though CHN has no official official projects - its all ad hoc)

–

In terms of the political / non-partisan angle, as long as you’re not doing something for a political campaign or party you’re pretty safe. Given …that state of the world right now… I don’t think Brigades should shy away from being political. At some point, the problems we’re aiming at are going to go beyond a technical solution. What I would recommend is to focus your Brigade strengths when thinking about your advocacy. Not everyone can translate the tech world speak into the government speak and back again. Not everyone can come in at the digital service delivery angle.

Hope that was helpful

3 Likes
8

Yeah this is also what I will allude to in my response, that I originally “stream-of-consciousness” wrote out in Slack

1 Like
9

In a sense I want to blend both the volunteer driven project and the one maintained by the core team, that is alluded to in @nFlourish’s slack post.

And the way I consider doing both is having two sort of project tiers.
We let things come organically if they are just ideas someone has, lets say its an issue like diving into property assessment data. We let that fester as a breakout group (tier 1) until they have some concrete project idea (edited) then, we need to consider where that project sits
I think that’s where the core team comes in. In terms of gatekeeping and being more hands on — navigating the ownership, maintenance, and sustainability piece for a new project, and any project that in the second step/tier becomes owned by the brigade itself or some other non-profit
The project is not in tier 2 until it is A) a project, and B) there is at least an idea of where the project will sit
in tier 2. Depending on whether the project is owned by the brigade or someone else, if the project team want’s more funding, software, possibly even human capacity they lean on the core team to help
they don’t have to vet every decision, but where the core team holds the access “keys” (for lack of better words) it acts as gate-keeper.

So in summary: Tier 1) Infant project idea or even just a topic ppl want to explore, Tier 2) concrete project idea and there is some sense of where the project sits (and how it will access increased resources)

1 Like
10

I also love the idea of learning vs working group. Is there a difference in the way resources are allocated to learning vs working groups?

After our first hack night, it seems the “too political” question isn’t as much as a concern as I thought it may be (which was mostly a symptom of trying to address an issue before it arose), but its something we’ll keep tabs on.

Thank you all very much for the insight!

11

So, CHN doesn’t allocate resources to individual groups/projects but rather focuses on the event itself. (We film the speakers in HD and have ASL interpreter.) Most groups resource themselves.

That said, not everyone has to do it that way. If you’ve raised money as your Brigade you’re totally allowed to tap into those funds to ‘go big’ on a particular project if that’s what y’all want

12

Got it. What if a project requested funding/resources? Would it be denied?

13

Under CHN it would, but other groups might set things up differently.