Merging webdev and participation infrastructure forums

(Pierros Papadeas) #1

Hey all

Due to recent organizational and programmatic changes we are trying to consolidate our discussion forums to get more traction around projects and keep everyone updated.

The proposal is this:

Re-use this category (“Community WebDev”) as the central place to discuss all things participation infrastructure. This would include (as a portal) and our various participation infrastructure experiments (like Markerpulse and Bugsprints). We could also rename this category to “Participation Infrastructure” and move ahead consolidated.

How does this sound?


I’m very happy about the idea to use this category and to simplify
communication channels. I have some questions about directly merging this
category and renaming it though.

The idea behind this category is to give people a place to come to get or
give webdev help, similar to Community Ops, with an intended focus on
helping out with community sites. Those sites don’t necessarily live under
Participation Infrastructure. Also, I think Participation Infrastructure is
more complex than just webdev, right? What I’m wondering is if the intended
audience/purpose would be the same or if it would change?

Also would you see any problems arise from having the Ops side of things in
its own category? I can imagine that if there is a Participation
Infrastructure category then the ops tasks for those projects would just be
discussed in that category meaning that ops volunteers would need to watch
both categories. Of course this is one of the advantages of Discourse, it’s
easy to watch multiple categories so they can be more fine-grained.

This isn’t the first time I’ve had an issue with figuring out the best way
to nest categories. In several cases the parent category and the
sub-category could be flipped depending on how you want to look at it.
Discourse currently gives us 3 levels to organize categories - category,
sub-category, and you could use the same colour scheme across categories to
denote a relationship. What I’m thinking is, if Participation
Infrastructure is the parent category, then it would make sense for
Community Ops to be a sub-cateogry, just like webdev, but we definitely
need our sub-categories as it is.

I think this thread would interest you - - as
it discusses some issues like this and we need to decide which path to take
to try to address them.

What do you think of leaving Community WebDev so named, and having
sub-categories for the different projects? This could include a
Participation Infrastructure sub-category, though I agree with you it makes
sense for you to use the main category for general discussion and
sub-categories for specific discussion. Or having a Participation
Infrastructure category separate from Community Ops/Community WebDev, but
with the assumption that they would share audiences and sometimes cross

The nice thing about Discourse is that this is all flexible, we can always
rename/name-back or merge/split categories if we change our minds later.

(Giorgos) #3

The email I just send to the mailing list where this proposal has announced


There are many interested parties following this list who expect
information for to flow through this channel. Most of
these subscriptions will fail to move to a new channel and the history
of this list and project to be practically lost in the mailing list
dungeons. On top of that a lot of links will break, as happened with the
un-announced change of the bugzilla components for mozillians (which btw
holds true for the #commtools channel subject and a gazillion wiki

Organizational changes in Mozilla have been really common lately. This
list (and the project) has survived a lot of them. Let’s not rename
project mailing lists based on Mozilla re-orgs. Let this still be the
official mailing list and why not for other community


(Nikos Roussos) #4

It totally makes sense. Regardless of current organizational changes I always thought it was a big fragmentation to have project based mailing lists (eg. comm-tools, reps-webdev, etc) instead of an umbrella integrated communications channel for all these. This is pretty much what other technical/webdev teams inside Mozilla already do. If we communicate it properly to all existing channels it should be no problem for those who are interested, to switch to a new one. That’s not a reason to fear change.

If one the main goals of having a communication channel is engagement with potential contributors, Discourse is a better fit as a more inclusive medium. All discussions are public and you can interact only with the parts you are interested in, without the necessity of subscribing to all of them. After all the platform is the web, not mail :wink:

On the same line of thought we should probably also merge irc channels.

(Giorgos) #5

? care to give examples? afaik project based mailing lists are all over the place.

(Giorgos) #6

We’re fighting the same battle here about contributors. And my point is that we will lose contributors with changes of that kind.

At the moment both mozillians and reps webdev projects are lacking contributors not because of the mailing list fragmentation. We had separate mailing lists in the past and the projects were absolutely active with many weekly contributions from paid and unpaid stuff.

All I’m saying is: Get the ball rolling again and if the blocker appears to be the separate mailing lists, then by all means merge them into whatever the people want. Doing so now, will result to the project losing total traction.

(Nikos Roussos) #7

Indeed, but checking webdev projects from Mozilla’s github and crosschecking it with lists index, you can also find a lot of them that don’t have a dedicated mailing list.

I can’t think of a good argument in favor of communication fragmentation for projects that are being developed/maintained under the same Bugzilla product. The only “problem” is that we may get from low traffic lists to a higher one. That’s the kind of problem that Discource solves.

I’m not implying that fragmentation alone leads to reduced contributors engagement. But it certainly doesn’t help. Having inclusive communication channels is part of getting the ball running again.

(Giorgos) #8

We agree on this and that’s because many projects don’t need mailing lists.

Again don’t try to solve a problem that doesn’t exist. If communication becomes an issue then please do.

(Giorgos) #9

btw here’s what’s happening: a discussion about a project’s communication channel is happening outside the communication channel of the project. :S


Right, I think the intention of this topic is to see how the users of the Discourse category feel, and it makes sense for the users of the mailing list to discuss how they feel about moving on the list. Of course it’s worthwhile for people to use both tools before forming strong opinions.

(Nikos Roussos) #11

Right. And also this discussion is not just for, so it wouldn’t make sense to do it at its mailing list.

From my perspective this is an existing problem.

(Leo McArdle) #12