Working Group Proposals

Development
1

Could it benefit Meshtastic to ask that platform recommendations begin as Working Group proposals?

I envision that the recent requests would concretize around an ad-hoc working group for each proposal, and the user requirements, benefits, and expected changes all would be listed so that the community could decide how to proceed.

I jumped on the Meshtastic project because I looked at other Meshing radio projects and like the direction it was headed. I hope that we make sure that as the project evolves that it can continue to meet those goals, and that this is through a formal process for making suggestions that will change components of how Meshtastic operates currently.

A workflow could be:

pre-Working Group -> Working Group -> Working Group Proposal -> Community Evaluation -> Road Map Inclusion / Road Map Hold / Road Map Exclude

New ideas are the life blood of a project, and as we innovate, capturing this energy will allow Meshtastic to grow.

2 Likes
2

I like the impulse here, but new ideas are a double-edged sword. Iā€™ve been a part of several open source projects which had an excited community that began to propose all kinds of things, which unfortunately led to scope creep and a lack of focus.

Iā€™d say formalization for a design / development process is really only needed when youā€™re starting to see problems with the existing informal approach. Iā€™ve only been watching this project for a few weeks now, so I canā€™t really say if itā€™s gotten to that point or not.

Itā€™s great to see so many people and ideas. I hope it continues, whether in a more formal structure or not.

2 Likes
3

That 100%
I literally see new features being proposed on a daily basis when the app isnā€™t ready while the core software is still unreliable and lacking.

4

Iā€™m sorry neither of you have stated your replies clearly.

5

Meshtastic is a young project, whilst it is nice to have new ideas coming from the community, development needs to focus on getting the main things done and leaving out most of the proposed features for (remote) future reference.

2 Likes
6

@Ride33Comfy I appreciate where you are coming from (and your enthusiasm) and yes - after Meshtastic is more mature and we have more developer hours per week I think this would be a fine idea. But I think the level of formalism you propose is a ways away. For instance, I remember the early days of Linus developing the linux kernel (starting from Minix) and it was more than a decade later (for a very popular project with hundreds of developers) that the LKM reached that level of structure.

New ideas are the life blood of a project, and as we innovate, capturing this energy will allow Meshtastic to grow.

I think new ideas are great and we should capture them, but we already have a pretty extensive list of ideas. But we are only now nearly completing the initial 1.0 release of a ā€œGPS mesh enabled communicator for hikers, skiers, friends [ and we added a python API also ]ā€). IMO at this stage of the project ā€œdevelopers who want to contribute time and testingā€ are the lifeblood of a project. :smiling_face_with_three_hearts:

As we iterate and select a list of workitems for 1.1 (and 1.5) we will decide on a few ā€œkey itemsā€ (probably some cleanup, repeater nodes, mqtt, remote attribute API, global messaging are high on the list) we will formalize those use-cases and development tasks. Most likely through a series of chats (where anyone who is interested can discuss) on the slack channel.

But fundamentally there are three requirements that drive our development:

  1. What features we think are compelling to make a simple/usable device
  2. Good engineering practice
  3. What each particular developer wants to work on. (And currently ā€˜activeā€™ developers is about five people)

So a long ā€˜standards trackā€™ given the small (but hopefully growing - because this is a friendly and fun project to work on) is IMO not yet the time.

1 Like