Style Council is just a fancy word for the musicbrainz-style mailinglist.
subscription to the mailinglist is open to anyone, and all members of the mailinglist are on the style council.
generally, when someone wants something changed about the style guidelines, or wants a new relationship added, they discuss this on the mailinglist
at some point, he/she will write this down a little more formally in a proposal, this is sent to the mailinglist with RFC in the subject.
this RFC is discussed, the probably is changed accordingly, and when discussion has died out the final version is proposed in an RFV
at this point, unless the RFV receives a veto within 48 hours, the proposal has passed and whoever proposed it will now have to make the changes to the wiki
xiainx: any questions so far? :)
xiainx
nope, that all makes sense :)
warp
cool.
the two largest problems we have with this process is that it's hard for members of the Style Council to keep track of these proposals
and it's even harder for newcomers/outsiders/people who don't read mailinglists to keep track of things and to contribute.
xiainx
right
warp
but, how we want to solve this we are not entirely sure. there are various approaches we could take, and we're all open to suggestions here too.
aCiD2` joined the channel
for example, we could take the part of posting a formal proposal away from the mailinglist, and have this be part of the proposal tracker in some way.
this could make it easier for outsiders to also leave their comments.
but it could make it a bit harder for members of the style council, because discussion about this stuff will be split up in two places.
navap
Something like the audo-editor elections perhaps? A notification is sent to the mailing list, but the actual voting (and discussions in our case) is in site. Also, discussions could be sent out to the mailing list like what happens when a user adds a note to an edit.
warp
navap: I am by now leaning towards having the proposal + comments be outside of the mailinglist, but keeping larger discussions on the mailinglist.
navap: proposal + comment could be something like co-ment.
navap
So pre-RFC discussion on the ML, and then nitpicking and tweaking in the new style app?
warp
navap: yes, I think I'm leaning towards that. but that's just my opinion.
navap
It sounds good to me.
warp
xiainx, navap: if you're not familiar with co-ment, please have a look at it.
Perhaps a readonly ML could be setup that gets notified abotu the status of a proposal and what comments are being made to them, that would separate the "official" stuff form mb-style that has pre-RFC discussion.
warp
navap: I would say have a nice rss feed for that, and include it on the musicbrainz front page, similar to the blog posts.
navap
RSS, nice. That would open it up to a lot more users.
Co-ment looks nice.
warp
xiainx: what languages / frameworks / etc.. are you familiar with?
xiainx
ummm well I've used the following before:
navap
It also looks like it may help keep discussions focused and short.
so i was thinking maybe python/mysql kind of thing
I also have to learn PHP by next september
warp
we're usually more keen on perl here, as you are probably aware of.
xiainx
okay
warp
xiainx: but if you for example want to integrate co-ment, python could be an option.
luks
wasn't the plan to get rid of perl eventually?
warp
xiainx: co-ment is open source and written in python. only an alpha release yet, so it may be a bit of a challenge to use it (little documentation, etc..)
ruaok joined the channel
luks: no objections from me :)
luks: unless we're moving to java ofcourse.
luks
if I remember correctly, we wanted to do NGS in perl because we could reuse some of the existing code
and then switch to python
ruaok
heh.
luks
I guess that means I remember it wrong? :)
ruaok
no. its just very unlikely now. :)
warp
:)
xiainx: anyway, to continue with feedback.
xiainx: I would prefer to have something up and running very soon, as early as possible.
nikki would mostly like to have as much discussion in one place as possible
nikki
I know we like splitting everything up across 10 different things though :P
xiainx
heh, well hopefully this system will track all of the official discussion for the proposal
warp
xiainx: so perhaps it would be possible to start with just tracking proposals, and if time allows integrate co-ment or something similar to be able to discuss the proposals in the tracker too.
ruaok: what are your thoughts on what kind of stack this should run on?
ruaok
google app engine?
one less thing for us to host. :)
warp
ruaok: that's not open enough for me :P
ruaok sighs
damn free software hippies
ruaok
my thoughts exactly.
warp
:P
ruaok
well, perl or java, I guess.
warp
ruaok: so python is out?
ruaok
I'm personally fond of python as you know.
but we're not using it in a deployed manner.
nawm python is ok.
warp
ruaok: I just think integrating co-ment would be valuable, and that is in python. but again, that's a direction _I_ would like.
ruaok
s/nawm/naw,/
as long as you damn open shource hippies stay off my lawn, I'm happy.
warp
xiainx: I hope you have enough for now to improve your application.
ruaok
but, I am all for being able to tack this onto something that already does a bunch of stuff
xiainx
hmm I'm still kind of confused about how we're going to "track" proposalls?
Like, each proposal would have space in the db and store the comments/etc. there. Then we could display it using the framework/co-ment?
warp
xiainx: well, start off with the simplest thing which could work.
xiainx: for me that would be the title of the proposal, the status (RFC, RFV, passed, withdrawn, more?), and some dates.
xiainx: and nothing else.
xiainx: well, maybe a link to the actual proposal, which would be a wiki page.
xiainx
yeah, that would be the simplest one, I suppose
aCiD2`
warp re: "proposal + comment could be something like co-ment." thats along the same lines as what I was planning too
warp
xiainx: once you have that up and running, then you can start adding more features. but if I end up mentoring you, I want to see the the minimal thing working ASAP.
xiainx
aye aye!
warp
:)
xiainx
for the backend... any thoughts on a database candidate?
i guess for the very first one, a text file would do, but that's pretty q&d
warp
we run postgresql for musicbrainz, sticking with that is likely a bit easier on the sysadmins.
xiainx
okay, easy enough
ruaok
actually, no.
the machine that this would run on, since app engine was rejected, currently has an instance of mysql.
we'd make better use of our memory footprint if we used mysql.
aCiD2`
hrm, have mysql improved there text field handling?
warp
ruaok: bah, you with all your different machines with different operating systems and different databases
:P
aCiD2`
gotta say, +1 for consistency between our products
ruaok
dont make me have you come over here to fix all that.
warp
lol
ruaok
aCiD2: that +1 is in favor of what?
aCiD2`
using postgresql instead of mysql
ruaok
ok, fine. that box still has 2.5gb of ram free.
aCiD2`
is it realy that much of an issue to remove mysql and install postgres?
warp
let's just stick to SQL-99 and it'll work on all of them!
aCiD2` pillows warp
warp definitely deserved that
aCiD2`
i hope that doesn't have alternative meanings
ruaok
aCiD2: we need mysql for mediawiki and for the blog.
aCiD2`
now I really hope it doesn't
oh I see...
heh
feh*
ruaok
I could only think of pillow biting. :)
warp
xiainx: feel free to poke me here on irc if you have any more questions.
xiainx
will do
aCiD2`
ruaok: if you struggling to think of something, I think we're ok :P
struggled* ffs, where have my typing skillz gone
ruaok
aCiD2`: oh, no. not struggling at all.
aCiD2`
lol
ruaok
I've always suspected you to be a little "funny". :)
