1. Understanding simulation data

Randomised chattiness

Version 4 of the model allows for randomising the "chattiness" of individual members of the simulated community. The model still allows us to choose a global chattiness level. This is modelled in the initialize-memberprocedure:

ifelse randomised-chattiness [
      let getrandomchattiness random-normal 0 1
      if getrandomchattiness > 0.5 [set chatty? True ]
      set my-chattiness 1 / (1 + exp (- chattiness - getrandomchattiness ))
      ]

my-chattiness is the probability that the member will be active at each period if she has not received any comment. The logistic function is there to make sure that it is always constrained between zero and one.

The nonlinearity of the logistic implies that the mean of the logistic of the sum of a constant plus a normal of mean zero is greater than the logistic of the constant alone. So, all other things being equal, a run of the model with randomised-chattiness == true results in a community whose average chattiness is higher than one where randomised-chattiness == false

The chatty? variable is only there for visual inspection when debugging the model, but it is not used in the estimation.

Policies

We consider three possible policies.

• Onboard: the community manager leaves a post to every user that joined the community in the previous period. In this model, exactly one new user joins the community with every period.
• Engage: the community manager leaves a comment to every user that wrote a post in the previous period.
• Both: the community manager enacts both the Onboard and the Engage policies.

In a model that studies capacity constraints, onboarding is not very interesting, as it requires limited capacity. So (and to reduce the computational load), we focus on the Engage and Both policies.

The capacity constraint is only taken into account when the community manager executes the Onboard policy. The reasoning was that this is a "cheap" policy, unlikely to make much difference in the end result when working with realistic capacity constraints. The estimation has been carried out with a capacity constraint of 100 comments per period. This corresponds to one community manager and a period of one week.

Capacity constraint

This is handled in the do-engagement routine. It relies on the max-n-of NetLogo primitive. When the constraint is allocated according to the rule of prioritising the most active users, the instruction is:

[...] ask max-n-of capacity latest-tick-active [ my-comments ] [...]

where capacity refers to the maximum number of comments that the community manager can use in one period; latest-tick-active refers to the agentset of members that have posted a comment in the previous period; and my-comments is the members-own variable over which the primitive works. When the constraint is allocated according to the rule of prioritising the newest users, my-comments is replaced by join-date.