On 30/10/2014 13:54, Nicolás Tamargo de Eguren wrote:
On Thu, Oct 30, 2014 at 3:11 PM, Paul Taylor <ij...@fastmail.fm
<mailto: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.
But /wiki and /doc are VERY similar whereas i assume without the
templates there will be quite a difference in what they look like. To my
mind introducing Git and Templates and lumping more files into the
already Monolithic codebase is not a good idea and is certainly this is
not making things simpler, I don't think this is the direction that
other sites are going and I'm now wondering if there are any other
'hidden goals' with this idea
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.
The difference is the kind of users that are used to writing wikis are a
bit different to those who write pure html and wikis protect users from
making invalid modifications. Consider Wikipedia do you think that site
would work better if users had to create valid html pages rather than
edit in the wiki style.
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.
Its one drawback, but what are the actual advantages I don't see them,
we shoudn't be adding any drawbacks.
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.
Well look at what you just wrote above 'and also probably their own
server setup anyway' you have made the assumption yourself.
To be clear I'm not against you being the final decision maker and only
editor for the time being, but we need to try test out the new process
before making changes like these, and what I'm against is making
changes to the way things works so that in the future it will be harder
for others to edit if decide want to spread the role. And putting a
dependency that the final editor has to have their own server running
just for modifying and viewing the changes is not a good thing, and what
happens if you get hit by a bus and we need a new style editor, Ian put
himself and nikki forward in the original proposal but I really don't
think having the main Musicbrainz developer involved (whoever they are)
is a good idea at all.
1. Developers have there plate full already
2. There is a conflict of interest between making the style proposals
and being the implementor
3. Concentrates control to fewer people, leaving musicbrainz exposed
4. Developers notorious for being bad at documentation
Maybe Im the only one thinking like this, and its not the most pressing
issue for me so I wont go on about it any further, but the absense of
discussion at the musicbrainz summit makes me feel I have a duty to put
alternative povs over.
ijabz
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
