On Thu, Oct 30, 2014 at 3:11 PM, Paul Taylor <ij...@fastmail.fm> wrote: > > I disagree, although one person is currently has now been put in charge > of the style process this is a new change that may need tweaking, and > future tweaking may involve delegating some of the style modifications > so we should not assume that only one person will always be making all > the edits. Nor we should assume that future editors will be git literate >
Both bitbucket and github allow on-site editing of files that does most of the branching and pull-requesting in the background. So it's not exactly much more complicated than editing a wiki, and it doesn't require basically any amount of actual git-literacy. Yes, it lacks being able to preview, but that shouldn't matter much - after all, right now you can preview how stuff looks in the wiki but not in /doc/, anyway. > this puts unneccessary restrictions on possible contributors > , surely one of the main point of the style guidelines has been they can > be contributed to my non-coders/tech. > That changes how? To be able to write a wiki page you need a starting template and/or knowledge of wiki syntax. To be able to write a static TT template you need a starting template and/or knowledge of basic html syntax. Both are similarly simple. In fact, with our old wiki templates for relationships, for example, using them was probably *quite a bit harder* than using TT would be (mostly because they were a badly written mess of a template, but people managed anyway). Plus, people can always put together a plain text draft on the ticket, to be made into a doc template by the person implementing it. > Also wouldnt this mean that unlike a wiki if we did move to the process > your are advocating you wouldnt be able to see how changes made looked > on the site before comitting without having a musicbrainz server setup. > Yes, this is the only drawback, but as mentioned previously, it seems minor enough. The people writing the final docs should have the (fairly basic) knowledge to know what to expect, and also probably their own server setup anyway. > Actually to me this points to a fundamental problem in Musicbrainz, > again and again assumptions are made all Musicbrainz contributors are > coders whose preferred OS is Linux , this isnt true, but assuming it is > true discourages contributions from the those not fitting into this niche How is this assumption made here? The whole point of this is allowing *everyone* to contribute, regardless of their coding expertise, by having someone who can take care of the more code-y stuff (instead of having non-coders fight confusing mediawiki templates). Actually, I don't see where that assumption is made *anywhere* in the project, to be honest, as a part-time coder (and non-coder when I started) whose usual OS is Win 8. But even if it was true elsewhere, I really don't see it here.
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
