"I like this, but as low priority"

[denise]

Several people have suggested some form of prioritization for their responses on dw_suggestions polls, such as "I like this idea, but as a low priority", or "I like this idea, but not before (insert favorite suggestion here)", or "I like this idea, but only if it doesn't take away from doing other stuff". I've also seen that kind of response being given in comments a lot -- "I like this idea, but we should only do it after reading filters", or "after cross-site friends page reading", or "after we fix (favorite issue)".

That isn't -- or shouldn't be -- a consideration in most cases, unless the thing you're mentioning is actually a direct technical ancestor to the suggestion being made. (For instance, if someone suggests a way to make finding a pretty journal style easier, it'd be a legitimate response to say "I like this, but only after we add some more journal styles; I don't think it's quite necessary yet".) The reason for this is the way that DW development works.

Basically, every project requires a certain skillset, which will be more or less unique to that particular project. Some projects require heavy backend/database knowledge, while some projects require heavy frontend design skills, while some projects need someone who's really good with Javascript. There's also a question of how hard something is: a lot of the time, a suggestion that people view as minor or low-priority is really easy to implement and would only take ten minutes of time for a fairly inexperienced developer, while a suggestion that's major or dearly wanted is harder to implement and would take an experienced developer several weeks. (Which is the case with reading filters: because the reading page is the most-accessed page on the site, changes to how it's rendered need to be planned and tested very carefully by someone with a lot of experience handling load and traffic issues, as a mistake there could bring the site to its knees.)

We have a few people who have the experience to tackle the really in-depth, technically-complex issues. Unfortunately, they're in very high demand, and they don't have as much time as they might like to devote to doing a lot of DW development work. There's also the problem that big, heavy projects like that make the most progress when you have solid blocks of time to devote to them -- something that might take someone twenty hours over two days could turn out to take up to 40 hours over two weeks, because of all the time it takes to get back up to speed after you stop and start again.

This means that the development of big stuff can look like it's going really slowly, while in reality, there are people working crazy-mad effort behind the scenes.

We aren't just limited to those people's efforts, though. We're blessed with a number of really enthusiastic, really dedicated newer contributors, who are really interested in contributing to the site even if they don't necessarily have the technical skills necessary to handle the big projects. The development time taken to (for instance) change the position of something on the page, or add a new section of text, or add a link somewhere, doesn't take away from the development of the big projects, because the people who are working on them are totally different.

The people who are working on the 'little' projects wouldn't be working on the big projects if they weren't working on the little ones; they generally (myself included!) wouldn't be able to find anything to work on at all. And it actually helps us to have a wide range of 'little' projects for them to pick up and work on, too, because everyone who's working on the big stuff started out working on the little stuff and gained experience that way.

So when you're evaluating suggestions in dw_suggestions, please only evaluate the merits of the proposed addition or enhancement compared to itself, not compared to another suggestion or compared to your favorite proposed feature or bugfix.

Having a wide range of smaller projects for newer people to pick up helps us immensely, because new developers generally get lured in by a small project that really speaks to them or their use of the site, and the more of those we have, the greater the chance that a new contributor can find something they really want to do. And having a wide range of more complex projects means that as those newcomers gain experience, they have a greater range of things they can move "up the experience ladder" with until they have enough experience and skill to do the big huge sweeping stuff.

(And please don't hesitate to suggest something because you think it's so tiny that there's plenty of other important stuff to get to first! Suggest it anyway. We will get to everything that's logged as a bug sooner or later, and the sooner you suggest it, the greater the chance is that someone new will see your particular suggestion and go "I can do that right now!")

Comments

[softestbullet]

Sounds good! :)

[7rin]

I've looked at joining in the dev. side, but even looking at the basics page (can't remember the link off hand, but I'm sure it was once described as something along the lines of "the easy start page") I got utterly mind-confused!

I'd like to suggest a dead dead basic training place where enthusiasts such as me but who've got almost no knowledge (other than perhaps some (to me) basic HTML), but then that'd take away from those who're having to 'teach' having time to actually work on the issues.

Damn catch 22 situations! Doncha just love 'em? ;)

[yvi]

I'd like to suggest a dead dead basic training place where enthusiasts such as me but who've got almost no knowledge (other than perhaps some (to me) basic HTML)

We already offer that :) Seriously, there's lots of people who just like you just started with enthusiasm. If you are willing to read some stuff, listen, and ask questions, you are more than welcome. I'm sure denise or someone else can give you a few pointers.

[7rin]

Hehe. Ta. And yeah, I know I =can= ask, it's just being able to get up the bottle =to= ask, iyswim.

Also, see my reply to cesy.

[baggyeyes]

I'd need someone over my shoulder saying, "No! Not that! Not that! The other thing! and that thing!"

[cesy]

I've started a post to try and answer some of this. If it was the "Beginning dev checklist" on the wiki that confused you, I don't blame you - it took me a long time to work through that!

What have you tried so far? Have you got a Dreamhack yet? Were there any particular things you were stuck on, or just where to start in general? Am I right in assuming you were interested in coding rather than docs or support?

[7rin]

*Googles* Yeah, it was the "Beginning dev checklist" on the wiki that confused me. <g>

Haven't bothered with Dreamhack yet 'cause figured there was no point if I didn't have the first clue what I was doing. I'd much rather have at least a vague clue and then get things like DH.

Definitely the where to start in general.

Yup, coding rather than docs or support. While I haven't actually helped out in Support yet, that's been more because the questions I have looked at required more knowledge than I had at the time, rather than I know nothing. I've only got 128 (I think it is) SPs over on LJ for the similar reason that most've the questions are starting to get beyond my scope of knowledge. While I haven't looked at the docs side of DW yet, I have a vague concept of the theory from LJ - though only in the "posting to the relevant docs community to suggest a change" sense, rather than actually editing any of the docs themselves.

Forgot to mention, I'm off to nose at your post now, and'll be bookmarking it for when I do get enough time to read it properly.

[cesy]

Basically, getting a Dreamhack is the best way to start learning, as it's the easiest way to look at the code and start playing.

[triadruid]

I understand the low-hanging-fruit model, I do. But on the other hand, I think there's value in the common "How much do you want this/need this?" question when it comes to bugs or feature development. That's why my comments are phrased in the way they are - would it be nice to have everything immediately? Sure, but since that's not possible, prioritization is necessary.

That does NOT mean I expect the devs to follow my orders, of course. I'm here in exploratory (and free) mode.. although it does make me wonder if some sort of microsubscription model for features would help serve the same purpose with a side-benefit for DW. People could donate $X to 'sponsor' some dev to take a look at their favorite request, with the understanding that it's not a purchasing model, only an incentive. Posting what has had the most donations might give devs something to peer at a bit more closely, and would *probably* be tied to features that people would get paid accounts for.

[kyrielle]

I don't think we should suggest the implementation order, or the priority with which it's implemented, no.

But I'm not sure a bit more option isn't called for. My concern is this: if 55% of the people say to implement, but all of them really meant "sure, that sounds vaguely nice; I guess I'd kind of like it" and the people who voted against it are vehemently opposed, that's also data. (Of course, I suppose that would come out in the comments, but that's why I think discussion like that is valuable.)

[ciaan]

Yeah, some of my "implement" votes mean "I WANT THIS OH SO VERY MUCH PLEASE YES" and some mean "I probably wouldn't use it, but I don't see why other people shouldn't have it if they want to." And there's not really a way to differentiate the "sure, why not" votes from the "YESYESYES" votes. (Not that it should affect priority, just inasmuch as it affects whether something gets added to the list or left off, if it does affect that. But I am not sure how many votes a thing needs to be added to the list. So I don't know if enthusiasm matters, or merely a lack of disapprobation.)

[yvi]

Oh, thank you so much for this post. I was just about to rant about that in my own journal - I know people don't mean it like this, but it comes across as telling the volunteer devs what they should do with their free time. We already have priorities in our bug system.

I don't want to feel like my work is worthless by reading comments about how something like what I'm working on should be the lowest priority.

Yeah, I had a bad night. Please no-one tell me how this is completely not how people mean it. I know that, it just comes across really badly to people who first need to fix a few really low-priority things before they can even do anything else. We are not wasting our time with that.

Also, we don't have enough babydev-bait at the moment :)

[cesy]

I don't want to feel like my work is worthless by reading comments about how something like what I'm working on should be the lowest priority.

I see what you mean. I hadn't thought of it that way round.

We're short of babydev-bait? Hmm.

[yvi]

I felt pretty low yesterday after reading a comment and thinking about my first bugs. I had a bad day yesterday and knew people didn't mean it like that, but it still wasn't plesant.

We're short of babydev-bait? Hmm.

I think we are :( I'll update my list in dw_dev_training later today!

[triadruid]

It's bizarre to me that we don't have enough babydev-bait. I'll have to get on that... ;)

Can you give an example of something you consider babydev-bait, by the way? A completed/in-progress thing, for calibration?

[yvi]

There are lists on dw_dev_training from time to time: http://dw-dev-training.dreamwidth.org/tag/babydev+bait

I did one three weeks ago here, but most of them are at least assigned by now.

Something like http://bugs.dwscoalition.org/show_bug.cgi?id=1436 or http://bugs.dwscoalition.org/show_bug.cgi?id=1414 or http://bugs.dwscoalition.org/show_bug.cgi?id=1449 is classic babydev bait.

[triadruid]

Nevermind, found this: http://dw-dev-training.dreamwidth.org/4108.html

[denise]

* changing the text of an error message to make it clearer
* changing the text on the page to include the site name or more links
* rearranging the elements on a page so that $thing1 shows before $thing2
* changing/adding an icon on a page, or adding different alt text, etc
* changing the links given on a particular page so there are more links/different links
* adding counts in some places (number of entries in the moderation queue, etc)
* cosmetic changes in general
* very very minor functional changes, like adding new settings

Things that are not babydev bait:

* anything having to do with the notification system (adding new notifications, etc)
* things that require heavy design work ("I want this to look different, but I'm not sure how")
* nearly everything in the importer, except cosmetic changes
* nearly everything in the crossposter, except cosmetic changes
* anything having to do with the reading page, for the most part (it's a high-traffic area)

In general, anything that's a minor change or tweak, especially if it's cosmetic, is likely to be good babydev bait. Some examples from dw_suggestions that would probably make it to a babydev bait list:

http://dw-suggestions.dreamwidth.org/37509.html
http://dw-suggestions.dreamwidth.org/36877.html
http://dw-suggestions.dreamwidth.org/36621.html
http://dw-suggestions.dreamwidth.org/34476.html
http://dw-suggestions.dreamwidth.org/34219.html

[triadruid]

Would it be reasonable to add a scope:minor, scope:medium, scope:major set of tags to dw_suggestions?

[denise]

We have those in Bugzilla; I didn't want to clutter up Suggestions tags with essentially a repeat of the same information, since developers (for whom that's most likely to be useful) will be interacting with the list in Bugzilla, not here.

[angelikitten]

I would love to work on problems like this (you know, the small stuff where it's unlikely that I'd break the site by working on it), but I don't currently have my own internet access ;_;