[development] Drupal core initiatives

[webchick]

On 6/13/11 1:08 PM, Daniel F. Kudwien wrote:
> And now that you went through all of this:  Welcome to the discussion!
Right. And so that's why it's perplexing to me that you want to add *yet 
another* channel for information, especially one that would require 
weeding through 10+ support questions per day. Ugh.

What we need is basically three levels of engagement:

1. "Outsiders" (non-top 20 core developers) and super busy people (like 
core committers): We want ONE channel of information, that's basically 
the highlights/summary of important issues that need our attention or 
input. We do not need/want to be involved in every single 
discussion/issue (fix the PHPdoc on X thing, what tag should we use to 
track our initiative?) because that is totally overwhelming and so much 
noise that important things slip through the cracks. Basically, we want 
to know about the following things:

a) We think a decision has been reached, and here's the decision. Feedback?
b) We're trying to reach a decision, and we need help. Here's where to 
chime in to help us reach it.
c) General status reports about "Hey, if you've been busy for the past 
while, here's what's going on and what things you should know."

That's the role that http://groups.drupal.org/drupal-initiatives is 
trying to fulfill. It's also attempting to act as a "Dashboard" of sorts 
to find the other channels you're talking about for people who want 
*one* place to go to find out where to find more out about/get involved 
with X. But the group is only a couple of weeks old, so we're still 
working on it.

If this channel gets polluted with things that are NOT this sort of 
"overview" information, then busy people (like me) will have to stop 
following it and become even *further* disengaged, and that is not what 
we want. This is why the group is closed to random posting. It's not to 
enforce some kind of "top-down decision making", it's not to stifle 
feedback/communication (the *entire point* is to solicit community 
feedback!!). It's simply to provide curation of content so if something 
goes through there, people know it's really effing important and they 
should pay attention to it.

If someone comes up with a patch to OG/g.d.o to add per-group granular 
create $foo permissions on g.d.o, I'd be *thrilled* and would gladly 
open it up to all users to subscribe so they can use their normal 
subscription workflow. For now, we use the tools we have, not the tools 
we wish we had.

2. Then, we have a per-initiative interest involvement. You don't care 
about HTML5, Design, or Internationalization, but you would like to 
follow info about configuration management and web services, because 
that's something you're passionate about. Perfect.

Each initiative has (or will have):

a) A group on g.d.o, which is a place for "meta" discussions to happen. 
All of these are listed at the top of 
http://groups.drupal.org/drupal-initiatives. Super important things will 
be cross-posted to the d-i group (as well as any other appropriate 
groups), too. Community initiatives pages probably belong here too. (The 
only reason community initiatives pages live on d.o is because g.d.o 
doesn't support [#xxx] syntax. Once again, patches welcome.)

b) One or more issues in the Drupal core queue around major actionable 
"chunks" which act as "broadcast" to the deeply-involved core 
development community (think sun, DamZ, and catch) who also doesn't care 
about the minutia I mentioned earlier, but definitely wants to review 
the progress of the overall initiative as it progresses and not get 
smacked with it in the face at the end. So people like you would 
subscribe to maybe 5-6 issues per initiative you're interested in, and 
each of those would get pinged once a week or so with a summary of progress.

3. Finally, we have people actively participating and doing the actual 
work in an initiative who *do* want the day-to-day minutia, since that's 
their actual to-do list. For them, we have a sandbox project where they 
can allocate commit access willy-nilly, come up with whatever 
component/tagging system makes the most sense to them, etc. This makes 
it *much* easier for new people to get involved in initiatives because 
instead of trying to find a tag in the core queue, and also makes it 
clear what stuff has already been committed to core and what stuff is 
still pending. It's a single place to go if you are interested in diving 
in with code.

I propose a workflow for this at 
http://groups.drupal.org/node/148184#comment-516654 which I /think/ 
helps mitigate some of the communication overload concerns you have. If 
not, please comment there and let's figure it out, because this is 
definitely a problem we need to solve.

The reason this is so janky right now is because initiatives are brand 
new, and we're still figuring this stuff out. It's not some kind of 
grand conspiracy to block people out of participation in these 
discussions. Exactly the opposite. People like Gábor and Larry 
*desperately want* feedback on these large architecture issues and have 
lacked it because of communication infrastructure. So that's one of the 
things I'm currently focusing on as part of my day job.

HTH,

-Angie