An example of data-driven and state-driven (via Data Objects) and event-driven directing of process.

Process starts at Fridays.
Moderator looks through the [Initial] Issue List.
If the [Initial] Issue List is ready, then start the Discussion cycle.
If the [Initial] Issue List is not ready, then don't start the Discussion cycle on this Friday -  this alternative branch is the default branch (branch with the strikethrough mark on the arrow), meaning that if the moderator does not review the Issue List and/or does not give the decision to start the Discussion, then by default the process will end here.

Discussion cycle.
Moderator will announce the Issues for discussion, the announcement will be sent as a Message to all the Voting Members, as a result of the announcement the Issue List shall be marked by a new state named [In discussion]. The basis for the announcement is either the [Initial] Issue List or the [Not Ready] Issue List, also during subsequent Discussion cycles one of the source data objects will be Issue votes [Final 2].
After the announcement, there will be 3 parallel branches (the Parallel Gateway is missing from the diagram).

One parallel branch is for moderating e-mail discussion, that activity (user task, would be better modeled as a subprocess task) will go on until it will be interrupted after 7 days by the interupting timer event.

The second parallel branch waits until the intermediate timer event fires after 6 days and then the Moderator will send the E-mail Discussion Deadline Warning as a message using a text from the Warning Text template document to all the Voting Members. The e-mail warning applies to the Issue List [In discussion], that will be included in the e-mail.

In the third parallel branch, the moderator will Check Calendar for Conference Call, if it is a Discussion Week then moderator waits until Thursday 9am and then Moderates Conference Call Discussion. If it is not a Discussion Week, then this particular conference call will not happen.

After 7 days have passed from the discussion announcement, the 3 parallel threads will converge and the Moderator will Evaluate Discussion Progress.
The Discussion subprocess will loop it there is no discussion of the issues or no sufficient solutions to the issues have been proposed.
Ready issues will be marked into the [Ready] Issue List, not ready issues will be marked into the [Not ready] Issue List. Essentially each issue in discussion will get marked with a new state: either [Ready] or [Not ready]. 

If the [Ready] Issue List is nonempty, then 
the Moderator will Announce Issues for Vote and the Collect Votes subprocess will be started. The affected issues in the [Ready] Issue List will be marked with a new state [In voting]. If the voting round is not the first round, then the [Adjusted] Issue Votes will be used for the announcement as well. The voting announcement message will be sent to all the Voting Members.

The Collect Votes subprocess starts from an intermediate event, from where 3 parallel branches will go on. The same 3 parallel branches will later on converge at the end of the subprcess. Both the start of the parallel branches and the convergence of the parallel branches should be modelled with a parallel gateway, the lack of those gateways is to be considered as a modeling mistake.

The Collect Votes subprocess takes 14 days to complete. 

In one of the parallel branches the moderator Moderates E-mail Discussion pertaining to the voting subprocess. The moderation activity is to be interrupted after 14 days by an interrupting timer event.

In the 2nd parallel branch, the moderator Checks Calendar for Conference Call. If there is no conference call in voting week, then the process flow waits until Monday 9am next week at the corresponding timer event and checks again. If there is a planned conference call in voting week, then the process flow waits until Thursday 9am and the moderator Moderates Conference Call Discussion. Issue List [In voting] is to be used as a basis for moderation.

The 3rd parallel branch will wait until the timer event will fire after 13 days (1 day before the deadline), after which the moderator will send an E-mail Vote Deadline Warning to all the Voting Members. The e-mail is based on the [Warning Text] template document and also contains the Issue List [In voting], which defines the scope of the warning.

In parallel to the Collect Votes subprocess there is another subprocess that starts whenever one Voting Member sends in his/her votes for the issues in the [In voting] Issue List. The votes sent in the message starts the subprocess with the Receive Vote event, the sent votes in the message are treated as a Member Vote data object. The Member Vote is the basis for someone (the moderator?) to Increment the Tally of the Issue (ie. counting how many votes have arrived for this issue), the new tally statistics is stored as the Issue Votes document, which someone (the moderator?) uses to Post Status on Web Site (and this is how this particular subprocess ends).

After the Collect Votes subprocess has ended (after 14 days), the moderator shall Prepare Results based on the Issue Votes. After reviewing Issue Votes, the Issue Votes shall be marked as [Final]. The moderator will then Post Results on Web Site and E-mail Results of Vote to all the Voting Members (probably by means of mass posting) - those two activities happen in parallel threads, the starting parallel gateway is missing from the diagram.

After the moderator has posted voting results to the web page and emailed results to all the voting members, thre has to be a check whether there were enough votes for each Issue. Unfortunately the model does not specify whether such a check is done by the moderator or whether that check is bone automatically by the information system. If it is done automatically, then the system has to be able to react after the moderator has finished the two prior parallel tasks. If the check is done by the moderator, then there should be a corresponding Task between the ending parallel gateway and the starting exclusive gateway. Anyway, by default it is assumed that enough votes have been sent. And if all the issues have been sucecssfully decided by a majority vote, then the process ends.

If enough members voted, but there are issues without a preferred majority solution, then if it is the 1st such occasion then the process flow proceeds with another Discussion Cycle. But if it is already the 2nd such occasion, then the process flow proceeds with the tasks of Reducing to 2 Solutions and E-mailing Voters that have to Change Votes (due to them having given their vote to the solutions that were reduced into oblivion ie. pruned out). This small subprocess does not give the precise ordering of these 2 tasks, but the ordering is indirectly given via the data object Issue Votes [Adjusted]. This small subprocess is followed by the moderator again Announcing Issues for Vote and a repeat of the Collect Votes subprocess.

If not enough members voted for the issues, then if the Voting Members have not been warned, then the moderator will Reannounce Vote With Warning to Voting Members via a message. And the Collect Votes subprocess shall be repeated.

If not enough members voted for the issues, then if the Voting Members have been warned, then the moderator will Reduce the Number of Voting Members and Recalculate Vote, the Issue Votes shall be marked as [Final 2] and then a check will be made whether issues have reached a voting majority among issue solutions. If not all issues have been successfully reached a majority decision, then if it is the 1st time then the solutions reduction subprocess will be followed by another round of Announcing Issues for Vote and Collect Votes subprocess. If it is the 2nd time, then the process will resume with a repeat from the Discussion Cycle.