Splitting bugs?

[yvi]

Heya,

I have been flirting with Bug 1365 - Add support for merging tags for a while (I have about 20 lines of code by now, even ;)) and I'd like to tackle it in detail over the next month. However, I have a bit of a logistical problem: I completely suck at JavaScript. I have this great JS user interface all in my head, but without taking another month to learn JS, this is not going to get written by me. I am pretty confident, though, that I can code the backend for this bug, a non-JS user interface and a very basic JS interface (just another text entry box on http://www.dreamwidth.org/manage/tags with a button next to it that gets activated when you select more than one tag and thus lets you merge two or more tags). So, when I ever get to that point, do I:

a) publish that patch as review? and commit? and open a new bug for a cooler interface
b) publish that patch as review? only and beg others to do the cool JS interface for me, then join the two patches for commit?
c) suck it up and learn JS
d) something else

This is way too early to be asking this, but I wanted to get this out before I forget it again.

Comments

[mark]

FWIW, I'd post this kind of question in dw_dev since this isn't a "btw, this is how to do things" it's a question on development.

That said, I think that A is fine. That's how the reading filters are right now, I have a crappy interface that works, and keep hoping day to day that someone will design a better one.

[afuna]

Hmmmm, do we have a bug open for that, btw? I wasn't aware that the reading filters subscriptions page was up for a redesign.

[mark]

Hmmm. I want to say 'yes', but now that you ask the question and I sit and think back, I'm afraid the answer is probably 'no'.

And yeah, that page is not what I would call done by any means. There's a lot that can be done there to make it easier to use, accessible, etc etc.

[exor674]

C!!!!!! (er, more practically A)

[afuna]

A sounds good, yup.