#bookbrainz-devel

CatQuest, they will be added simultaneously with barcodes and are already working in the backend.

bookbrainz-ws/master 82c0989 Ben Ockmore: pep8 and pylint fixes

Leftmost: sweet

ah also the bug i opened and *still* haven't gone around to answering/testing. sorry about that. hecktic with school and such :/

LordSputnik has changed the topic to: http://bookbrainz.org | https://github.com/bookbrainz | Want to help? Grab a task from http://tickets.musicbrainz.org/browse/BB | Meetings - Fridays at 20:30 UTC | Agenda: -style revisited (Ben/Sean), JIRA revisited (Ben/Sean), IRC bot name (Leo)

.

LordSputnik, Leo_Verto, around?

Yes

It's meeting time. :-P

:D

Hullo there.

Shall we get started?

<BANG>

I guess so ;)

So, -style... here's last week's discussion: http://chatlogs.musicbrainz.org/bookbrainz-deve...

Since then, reo has recommended a team of around 3 people be in charge of style stuff

Which seems OK to me, so long as they're going to stick around

It's my understanding here that "in charge" means "has final say" (just so we're clear).

He also said (http://chatlogs.musicbrainz.org/musicbrainz/201...) that we probably shouldn't require consensus if we have a mailing list approach

kuno: yeah, we were 10 minutes late :P

So, I think we can agree there should be an open way for people to collaborate on a guideline, then a smaller group of people to accept it as official?

Sounds good to me.

So, "open collaboration" say to me that it should be wiki-based

Wikis are terrible for discussion.

hmm, community input but the final decision is made by "the commitee"?

Yeah they are

Leo_Verto: yup

I think the main problem will be finding a commitee

I have a feeling that was how the MB style stuff was meant to work initially, but the style "council" kept changing/becoming empty?

Looks like the problem is how to chose and control that council then

"control" as in prevent people from going crazy

One'd think ostracism might solve that

Well, the commitee could be elected by the style group and only be around for a while before a new one gets elected?

But how is the "style group" defined?

User that have contributed to the style discussion in some documented way?

I think elections make a certain sense, but I also think that having no regularly-scheduled elections is a good idea. If someone on the committee chooses to leave or becomes inactive, then someone can be elected to replace them, but other than that I think it should remain fixed unless someone abuses their position.

Yeah, that was kinda my idea

the ability to unelect someone by vote of a majority of the style group can be added later

OK

So, reo said he didn't think a mailing list was particularly user friendly

What could we use instead?

too much democracy, just ask who wants to do it and pick one.

In general I concur, but groups.io makes mailing lists works like a forum

(or there apparently)

s/there/three/

Well yeah, but people have to sign up to groups.io then

yeah, we still need protection against malevolent or uncooperative council members

We could use JIRA comments and keep it in the same place as the style ticket

but how user-friendly are those?

LordSputnik, I think that places even more of a burden on casual users.

Is there a way to search JIRA comments?

Err, not sure

Either way, I can't see casual users taking part whether it's groups.io or JIRA based

the only way that would happen would be with a built in feature, or a more open communications platform (eg. blog comments/twitter/facebook/irc)

Is there a way we can get something forum-like backed by a mailing list so that people can use either and so that the latter doesn't require joining any sites?

Well, we can probably set groups.io to allow anonymous users to post

That sounds like a bad idea though :P

Ugh

Yeah

I'd say we'd need a way to track who's engaged in style discussions, especially if we want to add any kinds of votes

Well, actually, groups.io has login through Google and Facebook anyway...

...which not everyone wants to use.

But between groups.io registration, Google or Facebook, it's a fairly good choice of registration options

You've got to have registration to stop spam, and that seems like the least obstructive way of registering people

People would have to register for a forum or mailing list anyways

Not for a mailing list. Subscribing to a list is not the same as registration.

And we can enable anonymous subscriptions

I suppose it heavily depends on the list

So I'd vote for groups.io for discussion, a collaborative wiki for revisions of documents, and a style comittee to decide when a wiki page is ready to be made official

Didn't we decide a wiki would be a bad idea?

It comes down to this for me: we want a way that people can contribute without having to create accounts. It makes sense to me to create an alternate interface for people who don't like/aren't used to mailing lists, but making people create an account _anywhere_ outside BB is an obstacle to participation.

I'd prefer to use Github for style management, not sure how user friendly it'd be though

But branches and PR could potentially be really useful

Not to forget the built-in diff tool

Leo_Verto: I like the idea of GitHub, but I don't know whether that's as easy to use as a wiki for style contributors. I had in mind that the style comittee would take an "official" version of a wiki page and add it to some docs on GitHub, but we could alternatively have it all on GitHub

git is pretty user-unfriendly as well. I suppose not everyone needs to be making changes to the docs themselves, though.

Hmm, all on Github formatted with Markdown, easy to render, could potentially even be displayed elsewhere

Leftmost: I'm just looking to see if we can have groups.io allowing subscription without registration

Well, I think user wouldn't even have to use local clones

The GH webinterface does pretty much suffice for working on text documents

Leo_Verto: But then they have to be registered on GitHub :P

Well, they'd have to register for a wiki otherwise :P

Unless we hacked together OAuth for Mediawiki

Um

We could even keep the discussion on Github

It does sort of work as a mailing list

But it'd probably require registration in any case

Leftmost: it looks like groups.io may support subscription instead of registration

There's a subscription email address visible when you're logged out

We should confirm that, then, and possibly go with that for now.

I'm just trying it out

This seems like a good use for Captain Github Integration :D

Perhaps, although I don't want it getting spammy like bb-devel did :P

So, the style committee

One of us should probably be on it

If we're going with 3 people, we need another two volunteers from here :)

I think chrysn_ expressed interest in style a while ago

I don't think it's necessary that one of us be on it, but if you want to be on it, I've got no problem with that. :)

Heh

Leftmost: confirmed, groups.io doesn't require subscription

registration...

:P

Cool.

Ok, so, I'll set up a bookbrainz-style mailing list, we can announce the link here too.

Now... the style process

Do we require a JIRA ticket as well as a mailing list post? I guess discussion should just be open until the guideline is considered complete by the committee?

This is where Github might be useful

We could get rid of the JIRA ticket and work with PRs

Oh yeah, and "where should the docs be stored" is another key question

Leo_Verto: we could, and keep JIRA for code tickets only, since -style can in most cases safely be considered a separate thing

(apart from where it requires adding something in the UI or some schema change, but those would be exceptional cases)

LordSputnik, we could just use a git submodule if the docs are stored in git. :-P

Extending my idea of unified style-on-github, we could potentially use github pages to serve as the official style doc

Or we could host that on bb.org

reosarevok: hey, thanks for being here :) we're just deciding where to keep the docs - we've decided on a groups.io mailing list for discussion and a three person style committee to approve docs so far

Heh

Leo_Verto: I'm not sure it needs to be on bb.org - we already have some docs on readthedocs.org, and that also supports markdown

So we could host style there too

And it's super easy to update the docs with git :D

(the hideously out of date http://bbdocs-dev.readthedocs.org/en/latest/)

Webhook and pull on update

As I mentioned to leftmost (I think?) mailing lists are a bit tricky because a lot of people don't like them that might otherwise participate

But dunno. Might not be an issue at first :)

reosarevok, groups.io has a forum-like interface as well.

Oh, I see

(haven't touched it yet)

With Hashtags :D

Sounds okyish then? :)

reosarevok: I'm hoping not - and with groups.io, there's also a forum-like interface if people prefer that, and probably RSS feeds and all that jazz too

As someone who doesn't like mailing lists either, it seems pretty user-friendly

I'd say keep the docs in the same place you keep other documentation

Whether that's the site or somewhere else

My idea for user documentation was to have a "User Guide" which contained general info/tutorial/style guidelines - that would be separate to the developer documentation, and probably live at bbdocs.readthedocs.org

We've been dicussing the possibility of managing our style on Github

Advantages of this are: Issues, Pull Requests, multiple branches for final and release as well as the built-in diff tool

Leo_Verto: my only problem with Github is that only registered GitHub users can interact with it

Essentially combining JIRA and the Wiki

Leftmost: what are you thinking? :)

FWIW, one of my goals with style is to eventually condense it into a more book-ish thing

(in MB)

reosarevok: that's how I feel too!

So, a bit more of a guide and a bit less of a collection of random pages