Create mission statement, clarify purpose and scope

[niccokunzmann]

To invite new members and to collaborate, we should be on the same page: What is PyCal about?

We need to know:

• Who has access to which repositories? Who is responsible for a repo?
• What is the role of admins of the org?
• Why can have write access?
• What are the benefits to transferring a repository? What are the obligations?
• ... please add ...

Purpose I see (Benefits):

• PyCal.org promotes the projects and gives them more credibility and visibility.
• If I die, the repos are taken care of.
• ... please add ...

What is true for now from my view:

• Repositories must follow the AI policy and Code of Conduct.
• There is a common relationship: They are for calendaring and in Python.
• Repositories that are part of this, can be external and internal to the organisation.
• People part of the organisation are contributors to collective/icalendar.
• Repositories must have a FOSS license.
• There is an expectation that the one who transferred the repository is the maintainer and the only one who is allowed to merge PRs unless otherwise noted.
• All repositories of this org are listed on PyCal.org
• ... please add ...

Unclear

• Does PyCal ease maintenance?
• Does hosting in PyCal add to contributions/PRs?

Process

Instead of writing about what it could be, I would first like to harvest, what it is. That might be good enough. We probably all have (slightly) different opinions of what this organisation is for, so I would like your feedback on:

1. Common ground

• What do repository maintainers like you receive from PyCal.org and who provides that?
• Additions to Purpose
• What do you see PyCal already is?

2. Further questions

• What is unclear to you?
• What would make PyCal even better than it is?

I would love to read your input! @stevepiercy @tobixen @SashankBhamidi @abe-101

[SashankBhamidi]

My perspective on what PyCal is and what it gives me:

I originally created the GitHub org because I wanted a single place to switch between all our repos without juggling personal accounts and different orgs. That practical need turned out to be the right foundation; a neutral home that belongs to the team rather than any one person.

What PyCal gives me as a maintainer:

• A single org to watch and contribute to instead of tracking five personal accounts
• Credibility: repos under a named org feel more serious to outside contributors and funders than personal accounts
• Continuity: if any of us disappears, the repos survive

What I see PyCal already being:

• A home for actively maintained Python calendaring libraries with FOSS licenses
• A signal to the community that these projects are coordinated and not abandoned
• A place where NLnet funding applications can credibly represent a team rather than individuals

What I think we need to answer before we can invite more people:

The hardest question when I tried to invite someone recently was "what do you get from joining?" I didn't have a good answer. I think the honest answer is: visibility, credibility, and access to a grant network that grows with the team. But we haven't written that down anywhere.

My suggestion: keep the bar for joining low (FOSS license, Python calendaring, active maintainer) but write down clearly what membership means in practice; who can merge what, and what the expectations are.

[SashankBhamidi]

On growing PyCal:

I want to raise some thoughts on growth since it ties directly into the mission question.

The mission has to come first. We cannot do meaningful outreach until we can answer "what is PyCal and why should I care?" in two sentences. Until that is written down, every invite attempt will be awkward. I experienced this firsthand.

The website needs to become the canonical landing page for the Python calendaring ecosystem. Someone googling "Python CalDAV library" or "Python iCalendar" should end up at pycal.org, not at individual package docs. I have done some SEO groundwork but it needs to align with whatever mission statement we land on.

LinkedIn is an underused asset. I created a PyCal LinkedIn page. Once our current NLnet grant is officially announced and public, that is the moment to post about it. That announcement is genuine credibility with the outside world and will attract developers and potential contributors we would never reach on GitHub alone.

Maybe, the honest pitch to an adjacent maintainer is not "join our org" but "we are building a funded team, and a bigger team means we can apply for larger grants together." That is actually how I ended up here; I solved some issues, got invited in, and became part of something with real funding behind it. That story is repeatable. @niccokunzmann mentioned reaching out to the dateutil maintainer and I think that is a good approach. The pitch should lead with the grant opportunity, not the org membership?

Most of the outreach and promotion should wait until the current grant is public on the NLnet website. That is when everything we say about PyCal has external validation behind it.

[stevepiercy]

I'd like to see an actionable item list, focusing on what is PyCal now, and adds the missing pieces to https://pycal.org/about/.

[abe-101]

Purpose I see (Benefits):

Everyone has different strenghs. I may be good at programming (debateable 😉) but lack the knowledge how to foster a good open source project. Setting up policy's and CoC...
Having my projects be part of PyCal the projects can benefit from the communities expertise.

I fully agree with the items @niccokunzmann stated "What is true for now from my view".

Unclear
Does PyCal ease maintenance?
Does hosting in PyCal add to contributions/PRs?

I'm OK with those being unclear today. Time may answer them.
I'm aware of a few existing communites where the goal of them are to ease maintenance (or even hand it over) such as https://django-commons.org and https://jazzband.co.
Its possible that PyCal will become something like that but IMO it doesn't need to :)

What do you see PyCal already is?

When working on some of the Calendar tooling such as https://github.com/pycalendar/icalendar-anonymizer and https://github.com/mergecal/django-icalendar with others such as @SashankBhamidi it became a bit strange as who owns the project. We both owned it but did not have a common place to host the Repo that we collectively owned. PyCal solve that.