Several people have suggested some form of prioritization for their responses on
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
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!")
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ivorygates![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}