Next Step: list our projects

Community Ops
#1

Continuing the discussion from Meeting with Participation Infrastructure:

We had one very clear next step from our meeting with Pierros and Nikos from Participation Infrastructure - generate a spreadsheet with details on the projects our teams are currently working on.

This spreadsheet will help us:

  • Find overlap and opportunities to work together
  • Understand the demands on our budget and make sure everything is still accounted for
  • Create a structured plan for our team’s projects going forward

Because the sheet will be holding some internal only info, eg budget related info, access to the sheet will be granted on a need-to-access basis. If you don’t have access and you think you should, please ask for it. You can also suggest a project here that you want to make sure is included and someone with access can make sure it’s on the sheet.

It’s important to include all projects, even abandoned ones, so that we can use the spreadsheet to remind us to follow-up on resolving them, badg.us would be one example of a project we don’t think we’ll be continuing moving forward, but should be listed anyway.

#2

I’m quite afraid that there are more and more internal things that are being discussed without overall community input. I understand that there are some sensible information on it, but maybe splitting it into public/internal sheets might make sense?

I’d like to get access to the sheet, please add me. You can use my mozillians.org email address.

Just my input, feel free to elaborate on that.

#3

Could you explain what you think you’re missing from not being able to access this particular sheet? Having a specific concern will make it easier to come up with a solution.

Trying to guess at your answer, if it’s a list of projects each of the teams are working on, those should be in a wiki for better public consumption, not in a spreadsheet. An improved wiki page, at least for Community Ops, is one of the outcomes that depends on this sheet being filled in first.

I always hate when people respond to criticism with “well that’s not what we’re doing” or “look how open we’re being!” but I am really not understanding a problem in this case. I think the fact that I made this thread acknowledging that this spreadsheet even exists and what it’s for shows that we’re trying to be as transparent as possible, even with some information that needs to be internal. You said you’re afraid things are being done without community input, but I specifically asked for input. However, since this spreadsheet is about listing existing projects, there isn’t much input for community, outside of the respective teams, to give.

#4

@pierros - for the hosting things that were done through Community IT, I specifically left the old name to differentiate them. There has been debate in the past over whether those things feel under the mandate of our group, or if they were a separate project handled by @tad and Arzhel. Obviously moving forward things will be consolidated, but in terms of understanding where we’ve been, I think it’s valuable to single them out.

@tad - please let us know when you expect to be able to contribute to the pad. We’ll need you to fill out info for said projects that fit under IT rather than Ops.

#5

First of all, I really appreciate your feedback. Acknoledging the existence of an internal spreadsheet is actually very good, I didn’t see that point.

One point I couldn’t bring across (actually didn’t even mention it directly) is that there might be projects on it that actually shouldn’t be on there in the first place. With this approach you’d never find out since projects already on the list won’t be visible to people not having access to the sheet.

I’ve seen your thread about updating the wiki, so I won’t need access to the spreadsheet and wait for the wiki update.

#6

I’m glad, and thanks for your reply!

I think I understand your concern about putting things on the list that
shouldn’t be, I think your concern is that we’d be taking ownership for a
project that doesn’t belong to us and if we don’t let people see the list,
they can’t say “hey wait, that belongs to x, y or z group!” In this case
what we’re doing is listing things we’ve been working on under the label of
our group. I don’t see it as likely that we would add something to the list
that didn’t belong. Though I totally respect that this is hard for you to
judge for yourself without seeing the sheet, so I’m happy to address your
concerns if I can.

The list of things under Community Ops will be available soon as we’ll need
to refer to it to take our next steps. We’ll be using etherpads for the doc
sprint, so I foresee us copying the list into an etherpad that will be
easier to annotate for that purpose. There won’t be a need for that pad to
be private.