Perhaps it is time to try that again?

[Potherca]

I was planning on replying on #228, but I felt I'd better make this a separate issue, to avoid muddying the water.

---

After life happening, I've been away from active FOSS contributions for a while. Finding myself with more energy lately, I'm picking up where I left off. This project showed up on my radar. (Thank you, @fox91, for the friendly ping!)

Looking at the discussion in various issues, I feel that there are more people willing to invest energy into this project, and I would like to offer my advice. This text goes on for a while so, unless you actually plan on getting involved, it might not be worth your time to read it all.

And as always with free advice: You get what you paid for.

Summary of proposed action points:

• Create a CONTRIBUTING.md and mention it in the README.
• Create a ticket to discuss and decide what to use as (co-)maintainers communication channel
• Document the decided communication channel in the CONTRIBUTING.md.
• Use the chosen communication channel to agree on a common goal, to achieve more focus and combat fragmentation
• Create tickets for the work that needs to be done first, and add assignees

Enough already, what's the big idea!?

At their core, all software projects are the same:

People who communicate with the goal to collaborate through a process to create a planned product.

^{Verbs: communicate, collaborate, plan, create. Nouns: people, goal, process, product}

So what do we need? Communication, collaboration, planning. In that order.

I think, to a large degree, all the ingredients for success are already present:

• I have been in contact with @erikflowers, I have taken over the development of the project and I plan to move it or create a fork keeping it unchanged. […] I think the only thing that is not needed now is the fragmentation of the community around us, so I decided to leave the project here and keep it open until I was ready to take it on actively.¹

• To avoid fragmentation of the already small community of supporters, I am trying to carry out part of the modernization process here. If you want / can help you are welcome!²

• I agree combatting fragmentation is a good start. Part of the problem is that it is all a bit of a black box right now. There isn't any place where the ongoing collaboration is documented. No idea who is talking to whom. […]
  If there are any concrete plans, I don't mind helping out. If there aren't any concrete plans, I can help form them. I've got experience from maintaining and contributong to other FOSS projects.³

• Reading through several issues here, I sense the overarching issue with this project is there is no governance / "leadership", so nothing really happens. Which is a real shame. […] the project seems to have no leadership, or governance for decision-making. Who decides what should be done, how, and why? ⁴

• ✋ my vote is to consider this a SVG repo, and allow MR's to change/update those SVGs⁵

It just needs a bit of help getting things organized/structured so they can come together. As I said, I have some time available again, so I am willing to help come up with a recipe that works for the people involved.

So here's what I'm thinking:

Communication

The first thing that needs to happen is agree on a common "place" where communications can take place and document it.

I believe strongly that "If you build it, they will come". People that want to contribute will as long as it is clear how to do so.

The single most important thing is to have a channel through which all active participants can communicate, that works for everyone. This can be here on GitHub, elsewhere like Slack or Discord, or even via email. The most important things for such a communication channel are:

1. That it works asynchronously (as not all people will be online at the same time)
2. That it works for everybody (for instance, WhatsApp is banned in 48 countries⁶, so any maintainers from those countries would not be able to collaborate)

There might be other criteria, these should come from the people involved.

Action point(s):

• Create a CONTRIBUTING.md and mention it in the README.
• Create a ticket to discuss and decide what to use as (co-)maintainers communication channel
• Document the decided communication channel in the CONTRIBUTING.md.

Collaboration

Once there is a common channel through which people can talk, brainstorm, and exchange opinions and ideas, a general course can be set, and specific details can be discussed.

Things like, what to do, how to work, what to expect.

In order to move forward together, it helps to have a common goal. This helps both to maintain focus (and thus avoid doing things that are not relevant for the project) as well as decide which people are best suited for which work.

An example of this could be:

Goal

• What? Become an active, maintained, productive project.
• Why? To support the community and keep the project relevant and usable
• How? Communicate, Collaborate, Contribute
• Who? (Co-)Maintainers, Contributors, Users
• When/Where: Here, now.

This would be a sub-goal of the project in its entirety, specifically to get the project moving forward again.
It really doesn't have to be more than just a line or two, but it must be commonly agreed upon by the active maintainers, otherwise it will not help combat the current fragmentation. We need a common banner to work under!

Action point(s):

• Use the chosen communication channel to agree on a common goal, to achieve more focus and combat fragmentation

Planning

Once a communication channel and common goal(s) are in place, a consensus needs to be achieved on what needs to happen next, in what order, and who will take ownership of what.

Maybe the first thing to do is go through the ticket list and triage issues. Maybe it is most important to work on the designs first. Or update the scripting to improve automation. Maybe all three in parallel.

This will become clear through discussions based on the defined goals. Whatever the outcome, the most important thing is that each item has a clear owner, whom can be asked for details. Whether this is people who want to help, or questions regarding implementation details that touch other goals, or expectations regarding a feasible timeline. It needs to be clear who to ask. The easiest way is to just create a ticket for each item and agree that the assignee is the owner. However, depending on needs/desires of the group, other agreements might be made.

Action point(s):

• Create tickets for the work that needs to be done first, and add assignees

How to avoid future fragmentation / maintenance gaps

The most important thing is to make sure there is more than one person who has access, so the project does not stop when they are no longer able to contribute or maintain.

The second thing is to have a communication channel through which people can be reached outside of GitHub.

If a person does not have the energy to continue, they often also do not have the energy to communicate the fact. Co-maintainers can help each other, as long as there is an active conversation going.

The most important thing

It should be fun!

All the effort spend on this project is personal energy that can not be used elsewhere. If it (no longer) feels like fun, you should be able to step back, or walk away entirely. Guilt free.

It's great the project is useful to so many people but, at the end of the day, it's just a bunch of icons.

Both the project and the people involved should be able to survive (co-)maintainers going AWOL every once in a while, just as long as they don't go MIA.

There is safety in numbers. Lets collaborate.

Footnotes

1. Originally posted by @fox91 in https://github.com/erikflowers/weather-icons/issues/192#issuecomment-638859554 ↩

2. Originally posted by @fox91 in https://github.com/erikflowers/weather-icons/issues/228#issuecomment-712901541 ↩

3. Originally posted by @Potherca in https://github.com/erikflowers/weather-icons/issues/192#issuecomment-639509114 ↩

4. Originally posted by @BorisAnthony in https://github.com/erikflowers/weather-icons/issues/264#issuecomment-2238638381 ↩

5. Originally posted by @geoctrl in https://github.com/erikflowers/weather-icons/issues/228#issuecomment-1454172620 ↩

6. https://surfshark.com/research/chart/messaging-app-restrictions ↩

[BorisAnthony]

Thank you @Potherca, I agree with all this.
I would just add some steps before the action points you recommend:

• Call for core co-maintainer volunteers ("Core team" would have full repo and etc tool admin access as well as act as the usual "deadlock decision breakers" etc…)

• Core team candidates meet (virtually), introduce themselves talk about their motivations and hopes and skills and limitations. Ideally, self "shake out" to 3, max 4 people.

• Core team meet to discuss comm tools/channels, decide and do setup.

Because without someone having access to the repo etc, the project remains bottlenecked.

(I think also this is not just a typical OSS code project. Maybe because it has such a strong visual aspect, but there are questions that go beyond "does the code pass tests." i.e.: vision, strategy, "design", branding, etc… These things don't really fit in Issues tickets.)

So… how do we begin? Obviously the persons who currently "have the keys" need to kick this off. :)