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

[misskat]

Thank you for making this comment. I am sorry that there is a percieved barrier to Dreamwidth volunteering! That's definitely something that we want to address, and some of your points are particularly salient. I did want to break a few things out quickly:

I understand that IRC can be a little intimidating, but for our purposes, it's been the best solution. The IRC thing is an important part of our development culture, and has been since day one. Since before day one, actually. Real-time communication is the best way we've found to mentor new devs, and IRC is how our project has chosen to do that. Because it is a long-standing platform, there are a lot of resources elsenet to help, which we have linked to on our Dreamwidth Wiki page. That page also delineates the basics of IRC use, as well as explaining some of the Dreamwidth IRC idiosyncrasies. Does that resource help any?

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.

That all being said, if you or other developers prefer to communicate via the -dev community, that is absolutely fine! That's what it is here for.

You mentioned having some issues with changelog being an untranslatable mass of jargon. 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.

Finally, have you had a chance to look over our wiki? It is one of the easier ways to pop your head "behind the curtain" so to speak. In particular, the Getting Started: Development page seems relevant.

I apologize for the brevity of this response, but I need to head out for the day. I am flying to Portland this afternoon for a conference, and currently my suitcase contains one (1) t-shirt, all my meds, and a pack of gum. If you want to continue this conversation here, that works for me. If you'd prefer to chat in private, feel free to PM me on the site. Thank you again for bringing up your concerns! I hope some of the explanation and resources above will help make things a little easier for you and others.

ETA: I wouldn't normally respond to this sort of thing, but I know D is traveling today too, and likely won't have time to respond for a while. Also, I'd be very interested to chat with you (and anyone else) about particular barriers to entry that you've encountered when trying to get started with Dreamwidth. Unfortunately, there's no way to completely eliminate those barriers, but we've tried to make them as low as possible. It worries me that at least one person has been discouraged, and I'm invested in making sure that it doesn't happen again.

[ninetydegrees]

That all being said, if you or other developers prefer to communicate via the -dev community, that is absolutely fine! That's what it is here for.

I've heard this many times but it does feel like you're missing out if you're not on IRC at the right time. I know it's easiest for you guys but I do feel some regular communication thing is missing from volunteer comms. Like touching base if that's the correct idiom. Apart from Pau nobody does that. And seeing no activity and dialog going on in these comms doesn't really encourage you to post there. I kept all the questions I had to myself for a veeeerry long time or just PMed Fu. Still do sometimes.

[misskat]

I definitely see where you're coming from on keeping comms active-ish. I'll think on it and see if I can come up with something.

[swaldman]

Seconded. I don't mind using IRC, and I think it's a good tool, and I've benefited a lot from real-time hand-holding there - but I'm not prepared to be on it 24/7 and to scroll through logs every time I return to my PC to avoid missing something.
It should never be assumed that all, or even most, devs will know something because it was discussed on IRC. If significant decisions are made there, they need to be communicated elsewhere.

[deborah]

I wonder if we could ask people who are communicating in -dev IRC -- which is a pretty quiet community, all told -- that if either a question is asked/answered there, or a decision is made there, that one of the participants in the conversation agree to c/p the relevant lines and stick them as a post in this community behind a cut which summarizes the issue.

What often works for me in workplace environments is that the person who had a question answered pays it forward by documenting, and in this case the documenting would be posting to the community. That doesn't work so well for "decision made", but dw are pretty good about doing what needs to be done.

I'm trying to fight down the urge to say "we could write a bot to make that easier!" Because we COULD, but is that really a good use of our time?

[ninetydegrees]

*nods* The lack of documentation is really what bothers me the most about IRC. I mean oral history is fine but books? So much better. As a support volunteer it's also an issue: sometimes there's a discussion about a bug or whatever and it's confirmed and somebody's working on a fix except there's no announcement anywhere and unless you caught the conversation or someone mentions it in a support answer you don't know about it.

[misskat]

To be honest, there's not a ton of activity in -dev right now unless it's right around a code push, and that is primarily push-related triage. I'll keep an eye on things, and if there's a subject which should be documented, I will try to get that person to post the question and answer in the dw-dev-training comm.

[ninetydegrees]

What's going on right now with styles and the nav strip is a good example of what I meant in my previous comment and this is definitely not the first it has happened. There are several requests sitting in the styles queue and I have no idea what to tell people because I don't know where we're at and where we're going exactly with this. Even a let's wait and see before we sort things out post addressed to S volunteers would have been welcomed.

I don't mean this should be on you. I meant that sometimes direct communication between staff, devs and (support) volunteers would be nice and useful.

[misskat]

Ok, so now that I've had some more time to think it over...

What about a dev check-in? It would ask what you're working on, what you're interested, what your next step is? Forex, for momijizukamori, she's patching styles and SOMEDAY will finish the new styles search (after she teaches herself javascript, which is an endevour which I do not envy). She's also looking forward to the API being done so she can learn to work with that. That would be a sample reply-thing, maybe. (I actually just typed exactly what she said, so I'm not making this up as a hypothetical.)

This requires some amount of buy-in, and I suspect that's the biggest barrier. If no one uses it, then why do it?

ETA: Upon review, I should have posted this under my personal account. It's not the Voice of Dreamwidth (tm) talking; it's just Kat, a user of the site.

[ninetydegrees]

I think I'd like that but yeah it'd only work if most people contributed. Otherwise we're just back to what Simon said and having no idea what the big picture is and what some people are working on.
I never volunteered on LJ but I followed everything there and I think Carrie had something like that going on for Support and it was always nice reading it. I don't know if I'm imagining this, though.

[misskat]

For better or for worse, the Dreamwidth Support culture (and Dev culture too) have diverged so drastically from their LiveJournal roots that many of the things which used to work aren't applicable anymore. There are few who are grumpier about that than me, believe me.

90d, just to be clear, what you would like is a thread similar to the DW Volunteers thread, which occurs maybe once a month or quarterly. It would ask about progress on big/ongoing projects from senior devs, and whatever has been worked on from everyone else. If this is what you are proposing, I will propose it to the bossen. No promises that it will happen, though, for reasons which I will expound on below

One problem I can see is that this could create undue stress on devs who, for whatever reason, weren't able to get any DW work done in the timeframe. I know *my* reaction would be a panic attack, and then major avoidance of doing any more things... And I work here. Even if it isn't a required check-in, that expectation to report is still placed on the Dev, and I can see that backfiring quite spectacularly. I will still bring it to the bossen though; maybe there is a way around that.

[ninetydegrees]

I have no idea what's a good idea. I *think* it could be nice because at least someone would talk to us. Of course, it won't work for everybody, just as the current whatever works for some, don't work for others and cause them undue stress already.

Also I haven't done anything lately and it doesn't seem like it's gonna change so I *really* have no idea what's best or what most people want.

[jewelfox]

Seconded belatedly.

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