On Wed, Aug 21, 2013 at 12:07:47PM +0000, Xyne wrote: > On 2013-08-20 18:14 +0200 > Lukas Fleischer wrote: > > >+SVP is commenced at the time of the motion, with a discussion period of 5 > >days, > >+a quorum of 75%, and a voting period of 7 days. > > > Use the same formulation as the "Removal of a TU" section: > >Following the motion, standard voting procedure commences with a discussion > >period of 5 days, a quorum of 75%, and a voting period of 7 days. > > You can also replace "standard voting procedure" with "SVP" throughout the > document after its definition.
Note that I did not touch this sentence apart from formatting changes. > > >+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily > > I would change "i.e." to "e.g." as I see no reason to mandate that users > actually send the message with git directly (as this requires sendmail > configuration, and some users may only have access to webmail). The formatting > of the message itself is what matters. Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup. Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are: * Wrong patch format. Patches created with diff(1) or something else. * Patch is not sent inline. This makes it damn hard to comment on specific parts. * Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing. When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it? Also, the document says "should be sent" -- not "must be sent". Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice. > > To be honest, I don't see the problem with accepting the resulting document > either. Copying over a single document is no more work than applying a patch. 1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why? 2. Attaching a document makes it a lot harder to comment on specific parts by using the "quote" function of the mail client, like you did when replying to my patch :) 3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date). > > Perhaps we could also add an additional minor change to this patchset to say > that the SVP voting period ends either after the designated time OR after all > TUs have voted. With the upcoming changes to the AUR this will be apparent, > and > the AUR can stop the vote itself an possibly send an email to the list. Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :) > >
