?

Log in

No account? Create an account
LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

February 17th, 2004

upgrade [Feb. 17th, 2004|02:59 am]
LiveJournal Development

lj_dev

[avva]
There'll be a (very) short interruption of service on our Zilla tonight, as I upgrade the software to the latest version. It shouldn't last more than a few minutes, since I'll only make the final switch after getting the new version running and ready. Don't feel obliged to stay away from Zilla today, there's no way for normal Zilla activity to mess up the upgrade.

We're switching to Bugzilla version 2.17.6, the one that's also used on the largest and best known bugzilla site. Although not technically a stable release, it's very solid and its branch has been used and tested for a long time (the "stable" Bugzilla branch, on the other hand, has been rather dormant and stale over the last two years). I don't expect any data integrity problems whatsoever, but we'll keep a backup copy of the Zilla database at the moment prior to switchover, just in case any unexpected failures turn up.

As is the case with current Zilla's look, the new Zilla will be templated to look vaguely like LiveJournal; this cannot happen automatically (because templates changed too much between versions) and may not happen at once, so don't be alarmed if you see the default Bugzilla non-LJ-like design at zilla.livejournal.org — it'll be customized over the next few days if I can't do it all tonight (I just don't want to stall the upgrade any more, it's been long overdue).

By the way, in case you don't know what I'm talking about, please meet Zilla, our friendly LiveJournal bug-and-enhacement tracking database. Zilla helps us track bugs and hunt them down. It also helps us keep track of small enhancements as well as new exciting features we want to develop for LJ. Zilla is good for you. We love Zilla. Please use Zilla! This concludes our annual please-use-Zilla advertisement.
link22 comments|post comment

The problems with policy [Feb. 17th, 2004|03:01 pm]
LiveJournal Development

lj_dev

[bradfitz]
The Problem
Technically, implementing stuff is rarely difficult. Most hold-ups nowadays come from policy decisions. "How should it work? Why? What are the pros/cons of doing it that way?"

Before we spend a full day or week hacking something out, most of us developers aren't motivated to work on it until we know we have the design right, and it'll be acceptable, and the community will like it.

As the community grows larger, there are ever more voices, everybody chiming in with their opinions which tend to go every which way.

So lately it seems nothing gets done because there are a hundred people for and against each issue, which deters any changes from being made. (Of course, there are the people who argue that no changes should be made too, and that's often the best decision, but not always.)

My Solution
This might be the best solution, but it's the solution that I think will work for me, and in the end that's what matters, because I put code live. And I don't put code live which I don't have confidence in, and people don't write code unless they think it'll go live.

So here's what I want:
  • An issue comes up. We figure there are 2 ways to do it, but we can't decide which way is better, though we see the pros/cons of each. We're blocked on the policy decision.
  • I, or one of the other employees, makes a post to lj_dev or lj_biz about the problem, hoping there's an overwhelming response one way or another. We find out in the process there are actually 3 good ways to do it, and a 4th major voice not to change anything. Now we're really stuck.
  • Now one of us posts to the new system, currently lacking a name. Anyway, we make a post into it where we list the problem, then the 4 (or however many) major viewpoints we've heard, and a short synopsis of their pros/cons.
  • Now, people are allowed to vote on the viewpoints. But voting alone is gameable. In the end, I don't care what gets the most votes. I care about votes weighted by the intelligence of their arguments. So not only do you vote on your topic, but your vote includes 1 or 2 URLs which you feel best describe the arguments in favor of your vote, and/or against the other votes.
  • People can actively review the leading URLs for each voting item and change their vote/URLs at any time. If people decide to fuck with it and put Goatcx URLs in there, we just ban those URLs and those voters. I'm not concerned with that.
  • When activity has died down (and probably throughout the activity), I and possibly other leading volunteers/employees responsible for that bit of code will be reviewing the leading arguments and will make a final decision.
So in summary, I don't give a damn about numbers of voters on an issue, since numbers so easily lie. If a thousand people say "This candy is good, I want more" and one other guy says, "I studied that candy for 11 years and it kills you without warning after 6 months", I'm going to side with the single voter... his argument was better.

This whole process is what I used to do by hand, but there's just too much activity nowadays for me to sort through it all, so this should help spread the load.

Especially bad is that I often don't bring issues up to popular forums anymore (like news) because I don't want to be swamped. Nothing stresses me more than 6,000 comments of fighting. In the end I just want to hear both sides' best arguments and make a decision. This proposed system would let essentially elect a speaker for their party.

Thoughts?
link65 comments|post comment

navigation
[ viewing | February 17th, 2004 ]
[ go | Previous Day|Next Day ]