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

[marahmarie]

There's a balance that has to be struck between complete transparency and presenting a united front to our customers. There are very few things that happen behind truly closed doors, but it's a lot more efficient to do the bulk of our development behind a curtain, at least. For one, it helps reduce the feeling of exposure for new devs and provides a judgement-free sandbox where they can experiment, make mistakes, and get feedback without having every user on the site looking at them. It also helps provide some separation from the users who've forgotten their password, and people who need real-time assistance with development. IRC seems to strike a nice balance, in that you definitely need to seek it out to find it, but it is also super easy to find. It's one of the things that, in the past, we have had good feedback about.

IRC is an old protocol with a severely declining userbase, it needs to be downloaded to one's computer to be usable (though I understand there's a way to connect online through freenode.net, but I'm not sure if the functionality is the same) and it has an image problem: it came about in the days of BBoards as an offshoot of them and has the appearance of being for older and/or more highly tech-inclined users (and I'm "older" myself so there's no need to read anything too special into that statement). Nothing wrong with any of that but it might be scaring off people who didn't get online until the early 2000's or later, simply by looking or seeming harder/more fussy/more exclusive than it actually is (OK; it has that effect on me even without even throwing in the exclusive feel of the whole thing). Just my two cents on that.

I'm quoting what you said on that to pick up where I left off, though, not to really comment so much on IRC's pros and cons directly. Since I think its cons might outweigh its pros for the rest of us here who are not officially volunteering or working on DW just yet, my idea (the one I had to abandon when I said I could write more last night but I had to go) is that either instead of or else in addition to IRC we create baby_dev, so that if it's embarrassing for people to ask questions "in public" about coding or how backend DW works then keep this new community closed membership and not publicly viewable, like most official DW communities are, anyhow, and have available one or more active admins who can answer baby dev's questions within it; reserve IRC for actual dev chat while letting baby devs learn and grow in the new community with the established dev's support (and if this suggestion is actually more appropriate for dw_suggestions I'll gladly post it there, too).

I understand we have dev communities all over the place but I don't think potential baby devs like me either a) know they're already open for that sort of help and support and/or b) even if they do think that might be so, they're afraid to just throw themselves out there within them. For this idea to work, established dev support would have to be strong; questions posted within it would have to get answered fairly quickly and everyone supporting the community would have to be pretty obviously stoked about working on DW and helping others to grow in that same sort of role, otherwise I think potential devs might again think they're not wanted or simply lose interest in it.

You mentioned having some issues with changelog being an untranslatable mass of jargon.

Not exactly, but yeah, sometimes. Seeing TT mentioned completely threw me for a loop, which I can still recall because not much else has had that effect on me. I had a vague idea of Foundation being CSS-related to begin with (and, in fact, I still do, but it's just a vague concept). Luckily I've followed changelog for almost 10 years, counting the four years I followed it on LJ, so I know what some of our backend code looks like and what it does where and I stare at my own s2 enough to have some idea of what's being discussed the rest of the time. Most people don't stare at their s2, though, so I'm really rather strange in that way. For most people on DW I'm sure changelog makes about as much sense as reading through ancient Egyptian hieroglyphics. Backwards.

I 110% agree with you, which is why I'm REALLY happy that Dreamwidth does code tours. They came into being as a direct response to the "what the heck is that supposed to mean????" and/or blank-eyed stares that seem to happen whenever changelog is used. They break down the dev side of things so that non-devs (or newer devs, or non-dev staff) can see what's going on.

I agree the Code Tours are awesome and I always love reading them to see what's new and catch the latest. My quibble is we don't post every change within them and even when we post darn near all of them, they often aren't explained too well, depending on who's doing the tour (and this is in no way meant as a slight against anyone who has ever done code tours, since sometimes it's just the way it is). I would love if we had an archive (in wiki form? not sure where I'm going with that, exactly) of changes written in completely human understandable form just to aid in the process of understanding this site's history and what's been added, subtracted, and changed so far, but I understand time and people are probably both in very short supply for that.

I'm basically in agreement with swaldman's overall idea of not knowing where DW is going long-term in terms of what the backend dev is doing, what the point of working on each bug is, how resolving each bug contributes to exactly what specific goal besides keeping the site running on a day-to-day basis, and that communication is not all it could be to begin with, so I'm trying to tie in ways all of that could be improved not just for established volunteers and paid devs but for others who might want to jump in and make their load a lot easier.

[swaldman]

Please don't put words in my mouth - I don't have issues with "the point of working on each bug" and so forth ;-)

[marahmarie]

OK, I didn't mean that literally so I guess I should've phrased it better; my apologies for not doing so to begin with. I was responding to where you wrote:

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

I rephrased that as "what is the point of working on each bug" which was incoherent on my part and would've better served my meaning if I had added "in relation to DW's overall goals, since those are not being clearly outlined at this time".

I have a tendency to write like I sometimes think, which is quick and almost symbolically, and to not draw out contexts and explanations if I feel the basics are already known by those reading, so that was an example of yet another verbal/written shorthand on my part. But I always appreciate having that shortcoming pointed out. :)

[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.")

[misskat]

We do post nearly every change in the code tours. Generally, day-of-push changes get included in the next code tour. Sometimes they are missed, but that is very rare and certainly not the standard. If they're missed, it's because the code we use to generate tours missed them, and not a malicious/intentional thing.

[marahmarie]

So to reiterate, when ninety said that: "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.", was that right or wrong? I get the sense that maybe you think I'm just kicking at pebbles and calling them boulders but I'm not. I think it's important we have a complete record somewhere of what happens to code each day.