Retaining old IRC logs...
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Regarding the discussion about purging old IRC logs, I do not think we should just delete all logs older than 6 months.
If we want to move them off the server, that is fine, but I think they should be kept somewhere. Major meeting and some important discussions are in the logs.
Having a search function, however, would make the old logs much more useful.
--
Sent by Chessboard.
4 years
Game Controllers Working In Linux?
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Has anyone tested a game controller against the latest build in devel, with the SFML changes present?
I could not seem to get the directional pad or analog stick to make Alex move. The arrow keys on the keyboard worked.
I was testing with:
* Ubuntu 12
* An XBox 360 controller
I tried restarting the game and resetting the controls.
--
Sent by Chessboard.
4 years, 1 month
LaTeX class file for document submissions
by Quintus
Hi everyone,
I wrote a LaTeX class file this evening that I recommend to use for
document submissions as it gives all submitted documents a uniform
layout that provides all required information. The layout has a large
right margin so that you can easily make notes on the printed out
document. I think I managed to set the default paper size to "letter",
but I’m not completely sure if it worked out. I think "letter" is the
best option, because A4 printers can print letter paper usually, but not
the other way round.
The LaTeX class file is available for download here:
https://github.com/Secretchronicles/documents/blob/master/gd/gd-document.cls
Click the "raw" button to download it from that page.
In order to use it, drop it into your local TEXMF tree
(~/.texmf/tex/latex on a default TeXLive distribution) and run
$ mktexlsr ~/.texmf
afterwards. Once done, the new class "gd-document" is available for
use. The class is not really different from standard article
(resp. KOMA-Script's modified scrartcl, which this class is based on),
but it provides the mentioned standardised layout and a useful title
page. For a usage example, see the sources of the 16/1 document, which I
made available here:
https://github.com/Secretchronicles/documents/blob/master/gd/documents/te...
Take care to fill in all the meta information before \maketitle and then
be sure to call \maketitle. You don’t need to supply the document number
if you submit the TeX sources rather than the PDF file, then I can fill
it in.
Typeset your document with "lualatex", not with "pdflatex" please. The
class uses the fontspec package, which is incompatible with pdflatex.
Feel free to make any suggestions on additional commands to define in
that class file so that they’re available to everyone who wants to
submit documents.
Of course, you can continue submitting documents in any other format you
want, as long as it supports copy+paste. I can then transform it into
the unform layout. If however you chose to use this particular LaTeX
class, things will be easier for me.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
4 years, 2 months
[ANN] 2nd General Discussion - Request for Agenda
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
datahead has requested to hold a General Discussion (GD). For those of
you who have not yet attended one (well, there has only been one yet),
see further below.
This email is to find the agenda of the 2nd GD. PLEASE MAKE SUGGESTIONS
FOR THE SCHEDULE now so that we can handle as many topics as
possible. Having the entire team available in chat is a rare
opportunity, so make use of the situation BY SUBMITTING AGENDA
SUGGESTIONS. Simply reply to this post on the ML or the forum to make an
agenda suggestion.
Furthermore, we need to find a date for the GD. Remember that the last
GD took over 3 hours, so before making a suggestion ensure you really
have time at that day. While everyone can make a suggestion on the date,
please respect that the suggestions made by the TSC team members are
more likely to be accepted as those are the people making the final
decisions, and hence need to be available.
Note that §5 VotR mandates that at least two weeks have to pass between
the final agenda announcement and the actual GD. Holding the GD
immediately after laying down the schedule would have been a bad idea
anyway. People need to prepare.
As a difference to the last GD, datahead has suggested to prepare the GD
by publically submitting documents prior to it. I think this is a good
idea; maybe it allows to go through the meeting more quickly then last
time if everybody is well-prepared. To submit a document, please email
it in PDF format to the ML or to datahead or me. We will upload the
document to the TSC-documents repository then so it is available for
everyone. The document thereby is assigned a number, so you can easily
reference it if you want to write up a reply.
Documents can be used to lay down basic facts or to outline a long and
complex argument which might not be possible in the hastiness of
speaking live. When speaking, you should still give a short summary of
your main arguments, though.
Please only submit documents that actually relate to a topic on the
agenda. If necessary, request your topic to be taken to the agenda
first. Nobody has time to read through wealths of documents about topics
that will not even be covered in the meeting.
Two weeks before the GD there will be a document submission
deadline. Documents submitted after this deadline are ignored. This is
to give people time to read through all of them.
What is a GD?
A General Discussion is a scheduled IRC meeting of the entire TSC team and
a means to intensely discuss and subsequently vote on difficult
topics. Of course, anybody interested is invited to join and bring
forward his point of view and his arguments, even if he is not a member
of the TSC team, but allowed to finally vote are, in accordance with the
voting rules, only members of the team.
The discussion is moderated and follows a previously layed down
agenda. For each of the topics on the agenda, everyone who has announced
it previously will speak on it. IRC voicing is used to ensure the
speaker will not be interrupted; while he speaks, questions can of
course be submitted which will then be answered once he is done. When
all speakers have finished, open discussion starts (i.e. the IRC voicing
restriction is released). After that, a voting is held if it is
impossible to reach a consent.
There will be a more detailed announcement of the precedure prior to the
GD, so don’t worry if you didn’t fully understand how it works. To get
an impression, take a look at the last GD’s announcement[1] and the
actual log of the discussion[2]. In any case, be prepared to spend a lot
of time on it -- the last GD took over 3 hours, with only a 15 minute
break.
Quintus
TSC project lead.
[1]: http://team.secretchronicles.de/~quintus/general-discussions/1st-general-...
[2]: http://chatlogs.secretchronicles.de/htmllogs/2015-03-21.log.html#msg-2015...
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWuG9KAAoJEPHYeZ+8yLxPPJ8IAKHQEcy+PO5uKmcSQ9DKGF4Y
UUIiJvXjr8vEU9FdGzPhLs8XYUO5Jrso4ZWCtpobLlGLnmaJnV0s3pWUbsAkAJan
oX2BPI+ywpolDABnQoTt/xe9hDntKX7R/mR/f67pk9fRYzFLLEoU0deiwafCffgi
1IMCfjMT3FDn9xiNiSvkIYyjSx4ol1Cq22eVwR/dh343Ci3h8I3Arc6UDGjGiFb6
RJVWWiRn3aZ/WjZdzrCzWoE+JV6y+88xnsN0p0UsMNJwRJdFZTbXgkQG9/wKu6SF
SmjNEuned7FTH5JcoaRUMt6HgjJ+6j7T/vJXRHNhdPrM/CCLUYeKDE2oqISchpo=
=EAUG
-----END PGP SIGNATURE-----
4 years, 2 months
[Document 16/3] Story proposal by datahead
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
the following document has been submitted.
Title: The Secret Chronicles of Dr. M Story Development Document - Version 2
Author: Chris Jacobsen (datahead)
DNr: 16/3
Link: https://github.com/Secretchronicles/documents/raw/master/gd/documents/pdf...
Abstract:
> [ A story proposal by datahead, depicting Dr. M. as the heir of the
> Great Library, who likes to make Shakespeare quotes.-- note by
> Quintus ]
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJW98HeAAoJEPHYeZ+8yLxP4eQH/3hJjsgduKHvTD1OGkb1yHdd
AYLc4GN327FmZSJHogaCQ3e0zWm4V3wX4HGscT1b2VuiF9Rhq/xwrAsErQ8dCXgv
JpwnPfFRTqJr3CwsqcmZ30frvVaB5elEVtkQY+hkJeL/gT8GszZ/dF4QFpCcdSWt
rvxFBA9s1ziXrhxJEuBeYOMGbmmLmGzVn77sGBqcXaFsgChLkLS31TaXSTe7NxdE
XaZsGn/AROGryBsUWOvRvoGGWHCuk+XHp54dxLBgWPja5ycp09YtHpG6xAAcXvk7
zzfSfQI+G2+l43KsrAr8kxXacg9T750k0rEQ5hu2Y5IVRZuWQfgzuKC6mRjf9n0=
=C4xX
-----END PGP SIGNATURE-----
4 years, 2 months
[Document 16/2] Story principles suggestion by datahead
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
the following document has been submitted.
Title: Story Principles and Decisions for the Secret Chronicles of Dr. M
Author: Chris Jacobsen (datahead)
DNr: 16/2
Link: https://github.com/Secretchronicles/documents/raw/master/gd/documents/pdf...
Abstract:
> [ This is a proposal for story principles by datahead. It compares different
> approaches for stories with the current state of TSC and makes suggestions
> on the fields of graphical design, target age group, and story conveying. It
> does not make specific suggestions for a specific kind of story.
> – note by Quintus ]
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJW97xmAAoJEPHYeZ+8yLxPyIoH/3YkonIs55Xjlwj7sOBhCZ0b
JhaSUKANXvlkQ9zcFabO9m45C/n3Wb4m+5TkuErrhvlGp4SWZvgu0J1Ef8+VnRVx
phxuGUcfUsLHsJhV+uCndcJv0AjByUi5NmTL4OKxtf3xW5idl5AVMU+aePIs64Vm
jk/mDCmPCkceqMjASZgu0sXaG/snUaUDP+p/Xlk0xUiy6GhEWNldweNQ0ehm12He
Rt+f6k9h/QsR+n2zG4uSm0peydv56MeWN7ndgWPbquk3okmHGGcBOBVmjgMH6d3y
AO13fY2qfpuezr354yS329p976LGhNhCW/JMUpHjkinw5tW4MOMmtvLJ2FMJ6Rk=
=30sx
-----END PGP SIGNATURE-----
4 years, 2 months
[Document 16/1] Story submission by danfun64
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
the following document has been submitted.
Title: Unofficial Story Development Document
Author: danfun64
DNr.: 16/1
Link: https://github.com/Secretchronicles/documents/raw/master/gd/documents/pdf...
Abstract:
> [ This is the second draft of danfun64’s story document proposal.
> It outlines a dark story around Alex, Dr. M., Lord Ázdhôr and
> the mesmo slugs, which turn their victims into zombies. It features
> multiple different endings. – note by Quintus ]
>
> The faythians don’t know much about the dark lord, whom I still
> haven’t named yet. That’s why in some of the endings, they wel-
> come his taking over from Dr. M with open arms. Yes, Dr. M lives
> in some of the bad endings, and it is implied that he lives in the
> good ending. I also spared the lives of Haakon and his parents, and
> explained why he is sour and why he isn’t playable in the second
> campaign.
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJW9yfSAAoJEPHYeZ+8yLxPTh8H/ih0ylVDNP6kJY91ubD2EUtK
lW6Fhys0IGpdHSmY92sI5HVQVfMEZ7VF7GyFhSOxHLSRZss+1XTzw3LH+TGSfM7B
BabfAGZYKwR9ATrvrCCgR7EFmWIIvn8OhWcpxj16aIzG3DjbwJhWqw3ws9itaxPP
oPNr+aR3UqopKRXaDqE+3TIwrUCRQ+PEypWGS5njp3IncImKtlBEzZdv9uPlo3h8
CnMzIbrapFkY1mZjbzdBcOtULzdp+h6ef/kgOI3txwE/p2caGK8nDaqQ21ZjCmsN
uq75txD+ljYz7OVl4v3ASS0uCc2UAX10VT3hXBArTj19K9gqCLUOUKHOnTFW86c=
=zwIk
-----END PGP SIGNATURE-----
4 years, 2 months
VOTE ANNOUNCEMENT: Votings in the General Discussion
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
this is the
A N N O U N C E M E N T O F V O T E
for the votes we are doing in the General Discussion on April 9th. Since
nobody submitted any voting options, I’ll make some up for now so we
have something to vote on even if we don’t get the required majority for
changing the voting rules.
Still I do hope we get that one through so we don’t get cought in an
overly formalistic voting procedure. I apologise for not having seen the
problem of IRC meetings when writing the first version of the
rules. This is why we should change them. But that’s for the other
topic.
Allowed to vote is any team member, which as per § 1 VotR is everybody
who is publically listed as a member of the “Secretchronicles”
organisation on GitHub.
The voting period starts on 2016-04-09 with the opening of the
respective voting process in the General Discussion, and closes with the
closing of the respective voting process in the General Discussion.
In the General Discussion, each of the topics will be announced,
discussed, and then voted on (call for votes) if no consent is
found. When the voting is finished and all votes have been counted, the
declaration of results happens directly in the GD. The results will also
be published on the ML.
Any vote given before the call for votes is ignored. If no option
receives the most votes (but multiple ones win), a second vote is held
with the set of options reduced to those that got the most votes.
Each team member has the right to request a covert vote. A covert vote
means that a technical procedure is employed that prevents everyone from
seeing how anyone else has voted. It is intended to prevent conflicts
within the team or between users and specific team members, and you
should only request this if you really think this is required. More
openness is better for the project.
If the request is made, it must be honoured. I will announce the
technical procedure in that case.
The request must be made before the Call for Votes has been posted, any
further requests for covert votes are ignored.
The voting rules change vote has already been announced, so it is not
included in this Announcement.
Team membership I
°°°°°°°°°°°°°°°°°
Vote subject: Inclusion of kirbyfan into the team
Vote proponent: datahead
Vote options:
1. Yes
2. No
As per §2(2) VotR, this vote requires a 2/3 majority of *all* team
members. Different only if we accept the voting rules changes before
voting on this.
Team membership II
°°°°°°°°°°°°°°°°°°
Vote subject: Inclusion of skarfester into the team
Vote proponent: datahead
Vote options:
1. Yes
2. No
As per §2(2) VotR, this vote requires a 2/3 majority of *all* team
members. Different only if we accept the voting rules changes before
voting on this.
Bugtracker software
°°°°°°°°°°°°°°°°°°°
Vote subject: Which bugtracking software to use for TSC
Vote proponent: Quintus
Vote options:
1. Bugzilla
2. Custom solution
3. Flyspray
4. GitLab
5. Gogs
6. Mailinglist only
7. Mantis
8. Redmine
9. Trac
Translation software
°°°°°°°°°°°°°°°°°°°°
Vote subject: Which tooling to use for translations
Vote proponent: datahead
Vote options:
1. Provide only PO files (i.e. keep current state, no change)
2. Transifex, no PO files
3. Transifex + PO files
4. Weblate, no PO files
5. Weblate + PO files
6. Custom solution
Audience
°°°°°°°°
Vote subject: Whom to address with the game
Vote proponent: datahead
Vote options:
1. Adults
2. Everyone
3. Old children
4. Young and old children
5. Young children
Depth of story
°°°°°°°°°°°°°°
Vote subject: How deep should the story be?
Vote proponent: datahead
Vote options:
1. Complex story critically required to enjoy the game
2. Good story, understanding increases value of the game
3. A bit of story, the game is more about playing a level
4. No story at all
Themes
°°°°°°
Vote subject: Which themes to focus on?
Vote proponent: datahead
Vote options:
1. Shakespeare and his works
2. Mario references
3. Food
4. Zombies
5. Futurism
6. Magic
7. No specific theme
Narration
°°°°°°°°°
Vote subject: How to tell the story?
Vote proponent: datahead
Vote options:
1. All by text
2. Cinematic scenes with text
3. Cinematic scenes with speech, text as fallback if localisation is not
available
4. Cinematic scenes with speech, English as fallback if localisation is not
available
5. Videos, with text as fallback if localisation is not available
6. Videos, with English as fallback if localisation is not available
Lifes and energy
°°°°°°°°°°°°°°°°
Vote subject: Changing the life system to an energy system
Vote proponent: datahead
Vote options:
1. Yes
2. No
CEGUI/SFGUI
°°°°°°°°°°°
Vote subject: Which GUI system to use
Vote proponent: Quintus (on suggestion of skarfester [not TSC team])
Vote options:
1. CEGUI
2. SFGUI
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJW9b2rAAoJEPHYeZ+8yLxPZWcH/jtlbYJ8QFJBAeCxptc0ICsi
WlHRUb0GwGrvgOR87sLI7u363HsQDHptGjEO0StDUQAjfeumenIl4dQkdewGJChJ
gqxn+YX+303rRCINltGTZMvIc2IbgDh8nQQqnLjCxRIfNpenJQyuarLisYIuNBqE
xuSSsUnmklFztt9HBSN1u6Nv7wHadNynMXrWMEPObu+rmnApQfHE9E1eKfXa3v0o
GfhPynZiuIkJF34JmPSe62GfjPCLBXpLny1eE2l2ZJ7DRpYjH3GgJI926ylQjUrD
SD7HpIrR5gQe5h6EFU7EvE00HSYUh+MaaMvFUFqtobP2NljOwY8R60JNLPdUlHU=
=o9/c
-----END PGP SIGNATURE-----
4 years, 2 months
Tiny Clipboard...
by Chris Jacobsen
Since tinyclipboard is now a build dependency for TSC, should it be included in the Install.md file?
If I'm doing something otherwise wrong, please correct me.
Build output:
datahead@datahead-G750JW:~/TSC-Release/TSC/tsc/build$ cmake -DCMAKE_INSTALL_PREFIX=$PWD/testinstall -DCMAKE_BUILD_TYPE=Debug -DBOOST_ROOT=/home/datahead/boost_libs -DBoost_NO_SYSTEM_PATHS=TRUE ..
-- Building mruby statically
-- Building tinyclipboard statically
CMake Error at /usr/share/cmake-2.8/Modules/ExternalProject.cmake:1199 (message):
error: no download info for 'tinyclipboard' -- please specify
existing/non-empty SOURCE_DIR or one of URL, CVS_REPOSITORY and CVS_MODULE,
SVN_REPOSITORY, GIT_REPOSITORY or DOWNLOAD_COMMAND
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/ExternalProject.cmake:1542 (_ep_add_download_command)
CMakeLists.txt:135 (ExternalProject_Add)
I can see my tinyclipboard directory is empty, which is suspicious. It looks like cmake tries to use this in building:
datahead@datahead-G750JW:~/TSC-Release/TSC/tinyclipboard$ ll
total 8
drwxrwxr-x 2 datahead datahead 4096 Mar 22 18:41 ./
drwxr-xr-x 8 datahead datahead 4096 Mar 22 18:41 ../
datahead@datahead-G750JW:~/TSC-Release/TSC/tsc$ cmake --version
cmake version 2.8.9
-datahead
4 years, 2 months
VOTE ANNOUNCEMENT: Voting Rules Change
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
A N N O U N C E M E N T O F V O T E
3rd vote March 20th, 2016
This is a formal vote announcement as per § 5 of the Voting Rules
(VotR), which are available online[1]. A vote that is accepted by the
team results in a final decision on a topic and determines how to
proceed.
Allowed to vote is any team member, which as per § 1 VotR is everybody
who is publically listed as a member of the “Secretchronicles”
organisation on GitHub.
Proponent
°°°°°°°°°
The vote was proposed by datahead <cjj_009(a)yahoo.com> and me,
Quintus <quintus(a)quintilianus.eu>.
Vote Subject
°°°°°°°°°°°°
We make the following proposal to adapt the voting rules so they are
more consistant and more flexible:
- --------------------------------------------------------------------------------
Art. 1
§2(2) is changed to “The vote requires that two thirds of the team
members voting are in favour of adding the new person to the team.”.
§3(1)(Nr.3)(2nd sentence) is changed to “This requires a two thirds
majority of those voting, and the candidate for removal is not allowed
to participate in the vote.”
In §20 the words “of the team members” are replaced with “of all
existing team members”.
Art. 2
A new §5a is introduced after §5 with the following text:
§5a IRC Voting Announcement
(1) For votings held in IRC — as an exception to § 5(2)(Nr.3) — it is
sufficient to announce all available voting options in IRC prior to
taking the votes.
(2) If at least three team members are available in IRC and are not just
idling, it is possible to waive the two-week preparation interval and
vote immediately. The waiver requires all non-idling team members in the
chatroom to agree on it.
(3) Any team member can challenge a voting made under the conditions
of (2) above until two weeks after the declaration of results have
passed by approaching the project lead accordingly. If the voting is
challenged, it is treated the same way as if it failed (§12).
Art. 3
These changes enter into force immediately after the Declaration of
Results of the vote for accepting them.
Any votes running at the moment these changes enter into force are
transferred to the changed version of the rules and do not remain under
the old version.
- --------------------------------------------------------------------------------
For eased readability there is a diff on the voting rules text
attached. Please note however that voting occurs not on the diff, but on
the proposal above. The diff is only for convenience.
This proposal is a rephrased and adapted version of my previous proposal
and merged with datahead’s suggestions. It addresses the following
problems:
* Synchronisation between team membership voting requirements
acquisition and removal voting requirements. Both now require only
2/3 of the people who actually voted (Art. 1)
* Clarification that changes to the voting rules themselves need 2/3 of
ALL team members (Art. 1)
* Changing “cast a vote“ to “participate in the vote” for team removal
vote. This is for clarification.
* Deformalise voting pecularities for voting in IRC (Art. 2)
* Get this into force as soon as possible (Art. 3)
The second-to-last thing is new. When preparing the GD, I noticed
there’s a rather low participation on the scheduling and voting issues,
which makes it pretty impossible to vote on anything in IRC under the
current set of voting rules, as they require every single voting option
to be announced two weeks before the IRC meeting. This is needless
formalism if everybody is in chat and is fine with voting
immediately. Therefore, Art. 2 of the above proposal allows to postpone
the announcement of the actual voting options until the IRC meeting
itself (only requiring the voting topic to be announced two weeks in
advance). This is §5a(1). Even more, §5a(2) allows to completely squash
the two-weeks interval for the vote announcement if everybody in chat is
positively fine with it so we can have a flexible agenda to work
through. If we come up with a new topic to be voted on, we can under the
new rules do that on-the-fly, provided that everybody is fine with that.
The new §5a(3) ensures that people who were not in IRC when voting took
place under the quick procedure can make the vote failed so the same
topic can be voted over again in the more lengthy procedure with the
two-week prepration interval. This is to prevent anybody from feeling
ignored or embarassed.
Or in other words: If we are in IRC, formal hurdles are lowered as far
as possible. They’re only standing in the way there.
Vote Options
°°°°°°°°°°°°
Option 1: Yes (Accept the change)
Option 2: No (Reject the change)
Voting Period
°°°°°°°°°°°°°
The voting period starts on 2015-04-04 00:00 UTC, and it ends on
2015-04-18 00:00 UTC. It also ends if the sufficient 2/3 majority has
been reached.
Note that the General Discussion is scheduled for 2015-04-09. If there
is no final result until that date, the voting will be completed at the
beginning of the General Discussion!
Procedure
°°°°°°°°°
On 2015-04-04 I will post the public Call for Votes (CfV) that
officially opens the voting period. After that you may vote by either
emailing your chosen option to the mailinglist, posting it to the forum
into the topic containing this announcement, or — once the General
Discussion has been opened — taking part in IRC voting (detailed IRC
voting procedure is announced in the General Discussion).
Any vote given before that CfV was posted is ignored. The timespan of
two weeks between this announcement and the CfV is intended to give you
time to decide and prepare, to allow you making last efforts in
convincing others from your opinion, and to decide whether you request a
covert vote (see below).
If no single option receives the most votes (but multiple ones win), a
second vote is held with the same options (there are only two).
This vote is a special vote. As per §20 VotR, changes to the voting
rules document require a 2/3 majority of ALL TEAM MEMBERS. So please:
every team member should vote on this!
Covert vote
°°°°°°°°°°°
Each team member has the right to request a covert vote. A covert vote
means that a technical procedure is employed that prevents everyone from
seeing how anyone else has voted. It is intended to prevent conflicts
within the team or between users and specific team members, and you
should only request this if you really think this is required. More
openness is better for the project.
If the request is made, it must be honoured. I will announce the
technical procedure in that case.
The request must be made before the Call for Votes has been posted, any
further requests for covert votes are ignored.
Quintus
TSC project lead.
[1]: https://github.com/Secretchronicles/documents/raw/master/votingrules/voti...
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJW7y5lAAoJEPHYeZ+8yLxPOb0H/2n6OPU2FPZgtE3hLmulZEln
lBP3h2UpP0C7EjwKk9hyXjWxb2fYk2350pOhnXFLO+5HQJh4+B3R0eGjmJ9r5lQH
ptxNrMFjM6JooKqSNHiuYYvScrSRdVbwx/yzxfQBEzyC7PQSiZLlCwvPMk7eY3Qd
KCHCwxs84Vd95tWR209zKYejw7hFrnfMIpQ7lNVpGQ2gQhxxm95V9um3z85Txje9
1NknDuyWnt91gi4NwFdDuOYQnbvehq9v2s7qaQ5+oRIadTMAYkcDMXNnS/jR3aKn
Lx+nVKZffKYH3O170o9yIJMJqO3EKKIalvuTUwVzxzGjEzegpvv0GQwCZZKz6UU=
=FfCN
-----END PGP SIGNATURE-----
4 years, 2 months
