Emit event when new participant is added

[juliangruber]

When a participant is added to the balances array (check if current balances[address] == 0), emit an event ParticipantAdded(address). This helps create auxiliary services that track participants in a useful way.

This will help us to create a list of participant addresses for accounting purposes and for live dashboards

[bajtos]

When a participant is added to the balances array (check if current balances[address] == 0), emit an event ParticipantAdded(address).

Edge case to consider:

1. We pay scheduled rewards
2. Participant's balance drops to zero
3. The next time the participant earns rewards, we see them as a new participant

[juliangruber]

good point. I don't see a way around that, the consuming services needs to handle this case. For each payouts window, every participant will be re-emitted. That can also be seen as a feature, because now you can tell who participated in which round.

[Winter-Soren]

Hey @juliangruber @bajtos I would like to take up this issue if it hasn't been resolved yet :)

[bajtos]

Hey @juliangruber @bajtos I would like to take up this issue if it hasn't been resolved yet :)

Sounds great!

[juliangruber]

@bajtos why did you label this as Tech debt? To me it's a new feature: Something that wasn't possible before should now be supported. Can you please explain?

[bajtos]

@bajtos why did you label this as Tech debt? To me it's a new feature: Something that wasn't possible before should now be supported. Can you please explain?

In my mind, this is about enhancing the smart contract to allow us to simplify the architecture of services, keeping track of participant addresses.

Quoting from the issue description:

This will help us to create a list of participant addresses for accounting purposes and for live dashboards

Issue types are always a bit fuzzy, I am okay with your decision to classify this one as a feature.

[juliangruber]

In my mind, this is about enhancing the smart contract to allow us to simplify the architecture of services, keeping track of participant addresses.

That's not tech debt. Quoting from wikipedia:

In software development and other information technology fields, technical debt (also known as design debt[1] or code debt) refers to the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one.[2] While technical debt can accelerate development in the short term, it may increase future costs and complexity if left unresolved.[3]

We haven't gone for a simpler design here, we have just not added a feature because we didn't see a need for it (plus, everything you add will increase smart contract cost).

Why is this distinction important to me? Because tech debt is something that is obvious that you should address it. With a new feature, it's not clear if it will actually improve the situation.