On 3/22/22 1:55 PM, Jonathan S. Katz wrote:
> On 3/22/22 1:18 PM, Andreas 'ads' Scherbaum wrote:
>> On 22/03/2022 14:41, Jonathan S. Katz wrote:
>
>>> Why do this instead of link to a wiki page? Editing the wiki would be
>>> a lower barrier to maintaining this.
>>
>> The maintenance "barrier" is really just adding name and email address
>> once
>> you create the next CF in the Django admin. And you have all the data
>> in one place.
>
> More that a few people manage the pgweb content vs. the entire community
> manages the wiki.
>
>> This patch shows where the Commitfest Manager is, recognizing the huge
>> amount
>> of work people doing for this project. And it adds a contact option
>> right where it
>> belongs. The additional page is a nice touch and can be left out, but
>> it does not
>> hurt to have it.
>
> In general, I agree with this, but I don't think that a patch to pgweb
> specific for CFMs is the answer per se.
I read the patch too fast and didn't realize that it targeted the CF app
specifically. I apologize.
Reviewing this again, I believe we can have multiple CFMs per CF. So
this would need to be a one-to-many (or many-to-many, see below)
relationship. It would be one-to-many if we do not leverage the existing
User model, which contains name/email, or many-to-many if we use User.
This could be accomplished in a couple of ways:
1. Stick a ManyToMany field on Commitfest to User
2. Do something similar to the "Committer" model[1] but have it act as a
join table e.g. "CommitfestManager" that can point to User and Commitfest.
This would change the queries in the views, but would ensure we capture
everyone who acts a CFM for a CF.
(I'm not a committer on the commitfest2 app, so at best I can review for
now).
Thanks,
Jonathan
[1]
https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=blob;f=pgcommitfest/commitfest/models.py;hb=HEAD#l14