On Sun, Dec 19, 2004 at 08:31:34PM +0000, Grzegorz Adam Hankiewicz wrote:
> There are some issues not done by other translation projects, like
> the translation of svnbook.red-bean.com. I personally consider this
> a negligence if not done, and the explanation to the fact that I
> already have 4 other volunteers for the Spanish project. Enforcing
> such simple rules helps the visibility of the project at the cost
> of a negligible effort on part of each coordinator. Your (meaning
> developers) lack of interest in these issues astonishes me.
I think you're trying to push a lot of formality on the project where
there currently is none. The Subversion project in general has worked
very informaly. There are very few "roles" and certainly none that are
"elected" per se. For instance I have the role of "Release Manger" but
nobody really elected me, I just do the tasks that the "Release Manager"
does. If someone else needed to do this task then there wouldn't be an
issue.
This project very strongly tries to stay away from the concept that
someone is in charge. I think you're completely misunderstanding what
people expected of the cordinator for translation projects. Ultimately,
the reason that role exists is because of this simple truth: Translators
probably don't care about most development discussions and vice versa.
In my opinion, the point of having a cordinator wasn't to have someone
in charge, but to ensure that someone involved in the translation
project was reading both sets of lists and could cordinate between
developers and translators. It was not to write a set of rules that
they expected translators to follow.
This is of course not to say that we don't and shouldn't have policies.
Nor is it to say that someone doesn't need to propose and write them up.
Rather, policies are discussed, usually by posting an email to the list
suggesting a change and then a discussion and then ultimately a commit
to alter the appropriate file(s) to enact that change.
However, you simply wrote up a set of rules dictacting to the developers
how we should interact with the translation cordinator and also setting
up this voting system for the cordinator. Unfortunately, I can't see
where you brought this up with the developers and discussed it. As a
result you're created the perception, rightly or wrongly, that you are
dictating project policies on the developers. Which is drastically
different than the developers are used to doing this and they didn't
like it.
Ultimately, I think the developers are less concerned with formal
policies as they are with effective communication. So let's have a
discussion about your specific *PROPOSAL* because I don't think it's
been accepted as a policy yet.
> Besides, I wouldn't expect suggestions to the chapter related to
> the translation community. I expected you would contribute to the
> second chapter. Things you could specify:
>
> * Two people are required to have a translation project hosted in
> the main repository. Rules for these people to be available always
> to the Subversion community.
What sort of rules are you talking about here. It's entirely unclear to
me what you're suggesting here. We already have a TRANSLATING file. If
you have specific sugestions for improvement please make them.
> * Write access to the repository doesn't mean a translation project
> can duplicate lots of other files in it, available elsewhere. From
> size optimisation point of view, you could argue the .xcf files of
> the repository are a drag. Gimp handles without problem .xcf.gz
> versions of them, which are on average less than one fourth of
> the space. Not a problem now, but think of scalability.
Well I think you're talking about what we would hope would be common
sense. But this discussion has already been had. If you'd like to make
a suggested change to HACKING or TRANSLATING to document the results of
that discussion please do.
As far as the .xcf files. Is that really a problem. I think the
dispute over duplicating things in the repository before was about
duplicating things that didn't need to be changed. Obviously the .xcf
files need to be altered.
> * r11950 showed that non project members should not write directly
> to the project reserved area, and the following outcry questioned
> my actions and authority. I specified this on the translators
> section, but it wouldn't hurt to say again that the coordinator
> of the translator is capable of making the correct decissions.
Well I don't think the cordinater has any greater authority than any
other translator. Their role isn't an authority role. They serve as a
communication filter between the developers and the translators so that
both are kept aware of developments on the other side that they might
not be aware of.
The style of this project is collaboration, not dictation.
That's not to say that you were wrong in objecting to Daniel's commit.
I have no idea. I don't speak Spanish and have no basis on which to
judge that. However, as was pointed out at the time the lack of a
public comment before the reversion of his commit made some people
question what was going on.
The other objection you had was about the origin of the change. I agree
with the discussion previously. We trust full committers to know the
license of the files they are changing and to ensure that the commits
they make come from compatable sources with those licenses.
> * I have received emails where people expressed that I irritate them.
> Well, I'm not here to make friends, but if there is something
> specific I'm doing wrong and you can put in clear words, I'll
> avoid doing it.
See the beginning of this email.
> * What to do with the people with write access who have lost interest
> in whatever they were working on. Do they lose write access? If
> so, what time period is given?
People come and go from projects and sometimes come back. Losing
intrest, being busy, etc... is not justification for removal of commit
access. The only reason commit access should be removed is if the
committer requested it or if some action the full committers decided
justified such removal.
We have many "inactive" contributors who have stopped by and contributed
a change form time to time. And many regular contributors who have
briefly been too busy do continue contributing for a short period of
time.
This is an open source project not a job (for most of us anyway),
peoples level of commitment will vary.
> * Ok, so I'm terribly bad. Subversion development has stalled because
> I flood the mailing list with senseless request and only
> contribute flamewars. What are the things I would have to do for
> the community to want to change me as coordinator? How would this
> take place? Are we talking about some hidden chit-chat on IRC?
There is a private email list for full committers. But I have to ask...
Do you really believe that the above is going to happen? Can we not
just deal with it if and when it does? I don't think the developers see
this as something they need a policy for. Especially, since I don't
think the developers see the role as an authority role, which you do.
> * Who is the person in charge of translation projects? Is it still
> Erik Huelsmann? What does he have to do with regards to the
> translation project? Is there anything we (I) have to do as in
> progress reporting?
No one is "in charge". Erik has certainly worked to make translations
go as smooth as possible and has worked to cordinate all of that. But I
don't think he's ever taken on the role of being the authoritative
decision maker on translations. Rather, people post suggestions and
other interested parties post responses. If a consensus forms then the
action is taken. If a consensus can't be reached then a formal vote
might take place, similar to how we decide what to port to the next
release.
However, this has never happened as long as I've been involved in the
project. Because we work to reach a consensus.
> * Just like my opinion about svnbook.red-bean.com, you could make
> a point that translating the .po files is less work to do than
> translating a full book, and therefore a book translation cannot
> be started until the .po files are done, because every user will
> see those, while not everybody will read the book.
I'm not sure what you're getting at here. But this is a volunteer
project. People will work on what they find intresting or useful. It
would be silly to tell someone not to work on something just because you
don't like the order they're doing it in. If people want to work on the
book first or the .po files first or both at the same time, I don't see
why we as a project should object. We are after all taking free labor.
> * And another thing would be the translation of the main Subversion
> page. But I expect that this would be so painful for whoever
> admins it that nothing would be done, like the broken mailing
> list archives.
Tigris is not just a website setup to just run the Subversion project.
Think of it like Sourceforge. It's a massive web application.
Collab.net graciously hosts and administrates it for us. They do not
however, make specific tweaks to this large web application just on our
whims. Seeing as I can't look at the source and see if there's specific
support for multiple languages of the main page I have no idea if this
is possible.
Further, I would argue that your way of dealing with this issue is
completely non-constructive. You've chosen to rub salt in the existing
wounds of the existing known issues with tigris (i.e. the mailing list
archives).
I have managed to get changes made to tigris in the past, but certainly
not by suggesting that the people running it are unwilling to do things.
Some of these things took a significant amount of time to get handled.
A more constructive way of dealing with this would be to ask who to talk
to about this... And try to work with them to see that it happens.
> I didn't write those because I was already bored, and thought you
> would prefer to write them in proper English.
Well clearly you see these as issues. I'm not sure other people do. So
unless you try and take action on them nothing is going to happen. Just
remember that this is a collaborative project. Make suggestions, build
consensus, take action!
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 20 02:13:26 2004