On communications

[swaldman]

There was an issue I wanted to raise "informally" in the dev chat yesterday, but I had to leave before there was time. I have a certain amount of trepidation putting it in this perhaps-slightly-more-formal venue, so I want to emphasise before I start: This is (slightly) critical, but it is intended to be helpful. It is NOT intended as "wah Dreamwidth sucks you should do it better", and if it comes across at all that way please tell me so that I can revise. For the record, I still think DW is a fantastic project and that the staff are awesome :-)

I'm not active in Dreamwidth development at the moment, but I was for a year or so recently, and I hope to be again in the future, so I try to keep current on posts in this community. When I was active, and also more recently, I became concerned about communication between staff and volunteer devs. I noticed two related problems,

Firstly, that as somebody picking up bugs and working on them, I had very little idea what the "big picture" goals of the project were - what the big things that fu, Dre, and other heavy-hitters were working on were, and so where things might be going. It almost had the feel of a project that was considered "finished apart from tweaks" - and I don't think that that's how the staff think of DW (correct me if I'm wrong). I think the big work was going on, but in quiet. Perhaps that isn't a problem - it certainly didn't stop me from picking up bugs and fixing them - but I think it would help with community and motivation if there was a more coherent sense of "this is where the project is going".

Secondly - and closely related to that, perhaps - an unawareness of things that did affect me. For example, in the IRC chat last night I was unaware of what Foundation was. I had a look back through this comm's archive and found that it had been mentioned, but it had been mentioned almost in passing as something that was happening back in November last year - I couldn't see that anybody had actually explained what it was, so much as just said "we'll be using this now". That's not a specific gripe, merely an example of finding that major decisions were made without understanding the context, or sometimes not even knowing that they had been made at all until realising it through a chance remark some time later.
Now, I'm sure those discussions happened somewhere - but I suspect that they were on IRC, or perhaps in the Lounge, and never percolated out of those transient and/or invite-only spaces.

So, IMHO communication could be improved. That's the "problem" (perhaps too strong a word for it). I have a couple of suggestions that might help to address these:

1. A regular newsletter for developers. On a defined schedule, so that it doesn't slip - perhaps quarterly - explaining what the staff see as the big-picture items at the moment; the direction of things, any major projects that people are working on, and so forth. IMHO this would really help in terms of keeping myself and others feeling involved in the community.
2. If things are discussed and decisions made in private amongst staff, or in the Lounge, or even in public but on IRC (where folk who don't happen to be online won't know) - make a concious effort to make sure that these are communicated, presumably through this community. Try to reduce the amount of "things we know because we talked about it" and convert it into "things we discussed and then deliberately announced (or otherwise communicated)".

There we go; I hope that it's helpful, and that it can be seen that way.

Comments

[swaldman]

To actually comment on a couple of things here,

* As you've noted, "how to encourage new people to get involved" is not quite the same as "how to improve communication with those who are involved", although it is probably quite closely related. That's fine, so long as we don't start conflating the two.

* I'm not sure how your proposed community would be different to dw-dev-training, apart from being closed? (Granted, dw-dev-training isn't used very much, but I'm not convinced that creating a near-duplicate is going to help with that).

* AIUI the code tours do include all changes. I'm sure that the explanations could be better at times, but I also think that there will always be some changes that simply aren't amenable to being explained in non-technical terms, and are best described as "back-end magic" or the like.

* Given the last point, there is already an archive of changes in (mostly) human-readable form, in the form of the code tours: http://dw-dev.dreamwidth.org/tag/code+tour

[ninetydegrees]

Posting to dw_dev_training can be very intimidating. I can see why having something less public could be useful. OTOH I can also see why having something private could be a problem: lack of visibility doesn't always work as an incentive and private comms can send the wrong message too.

Code tours don't include 'surprise!new feature' changes, changes made 'on the fly', changes made in open bugs but included old changes which had been live for a long time already but only got their bug closed recently. These are exceptional cases and some might no longer be true but since we're trying to be accurate here...

[kaberett]

I don't understand why making an access-locked post to dw_dev_training is a problem.

[ninetydegrees]

I don't think it's a problem per se. I think dev_training has never sent a strong message due to lack of activity, conversations happening elsewhere and some comments at some point which weren't helpful and/or simply lack of answers if I remember things correctly so its purpose is unclear (not in theory but in practice). Also I think a mostly public comm can feel different from a fully private comm. I'm not sure I can explain it but I'd feel more comfortable with the latter (or a fully public thing). This is very probably completely irrational on my part.

Now I'm not mm_writes so...

[misskat]

Again, this comes back to buy-in. We have a comm intended to do what you want, but it isn't getting used. As a matter of transparency, I am not comfortable closing that comm as that will have exactly the opposite reaction to the one you are hoping to get. Imagine being brand new and wanting help, but the training comm is closed. You have to request membership (or even just pro actively join). That is a massive barrier to entry. If you want to make a locked entry there, then go for it. I want to retain the public posting option, though.

[ninetydegrees]

To be clear, I'm not favor of closing this comm. I believe I argued in another comment that this could have the adverse effect. I simply answered kab's comment.

[kareila]

Just chiming in here to point out that changelog_digest also summarizes all the code changes as they happen, and I personally find it more helpful to use as an archive. Code tours in the past have only reported closed bugs, although with the demise of Bugzilla that seems likely to change in the future!

[swaldman]

Code tours in the past have only reported closed bugs

Oh, quite right - I stand corrected.

[marahmarie]

How did I not know about this? Thank you for that link! *subscribes*

[marahmarie]

On your first asterisk: yes, I know, I know! I felt kind of bad for not sticking exactly to your talking points since I support what you're saying, and commented only because I support what you're saying, but I didn't know where else to finally tie in some related ideas of my own in a way that they were publicly viewable by people who are already paying attention and not likely to quickly censure any such thought.

On your second asterisk: it would differ mostly in spirit and intent by being more welcoming, supportive, private, and hopefully be much more helpful to more people in the long run. I'm trying to think of a way (right down to the very name of a community that could pull off all of these stated goals) to lower the intimidation/sort of stage-fright factor, if not eliminate it entirely.

On your third and fourth asterisks: I've often wondered if that's so simply because many changes are made right after code is officially pushed out. I am not sure (and can't be sure without doing a ton of my own research) if those changes get included in subsequent code tours or not. Again, I was not clear (but really not clear this time, since there was no precedent or tie-in for my thought anywhere else on this page) so I apologize for that.

(ETA: having just caught up on the thread, what ninetydegrees said, as well: "Code tours don't include 'surprise!new feature' changes, changes made 'on the fly', changes made in open bugs but included old changes which had been live for a long time already but only got their bug closed recently.")