Hey, yeah I'd be interested in helping out!

That would be great! Thank you! I'll see about adding you as a collaborator

What I would like to see:

• PRs must be approved by multiple (2? 3?) maintainers to get merged (I think github can do that)
• Maintainers can not approve their own PR

I think this is generally a good idea and would be willing to review/merge some PRs.
The idea for multiple people needed for signing of on a PR by @nxdefiant is good for heavy changes or things with wider reach, but probably overkill for most things. Maybe it would be better to get some simple rules on what to check before merging. Some points of the top of my head:

• Compatibility with current stable (and maybe most recent?) firmware
• Compatibility with dark/bright theme
• Useful/correct metadata (storage, supported hardware, tags)
• Get another person (at first probably @gfwilliams) to get a view at the PR if:
  • Some default for multiple apps is changed
  • "Basic" apps like Android, Bootloader, Settings etc. are changed in a relevant way
• Have a look at licenses if some new library is included in the repository

I'd be happy to jump on board as well.

I think I align with @halemmerich's thinking. Especially with having a checklist to go through, that would help me a bunch 👍

Also, @fanoush come to mind. Although you seem to be more active on espruino/Espruino and not here.

Thanks! I've just added @thyttan, @halemmerich and @bobrippling - I imagine there's more than enough of you for now - we may have to think of a way of stopping you from accidentally looking at the same PRs at the same time :)

@fanoush has contributed loads of quality stuff, but as you say I think it probably makes more sense for them to work on the main Espruino repository than the BangleApps one

I'm with @halemmerich on this - this is quite a small project in the scheme of things, and if I make someone admin it's because I trust their judgement. For most PRs I don't expect we'll need two people to sign off on it.

I added some initial thoughts (copy pasted from @halemmerich and added to) at https://github.com/espruino/BangleApps/wiki/App-Contribution - feel free to add to those/discuss them. I think it's probably good to be public about what kind of things we check - especially about things like when a fork is a good idea.

I'd be interested in helping out!

@ProgramminCat thanks! I think now we've got 3 maintainers (plus me) we're probably fine for maintainers - but if we need more or someone changes their mind I'll definitely be in touch!

Hi @thyttan, @halemmerich and @bobrippling - thanks for spending so much time helping out BangleApps - it feels like things are going really well.

However right now the amount of GitHub emails I have to sort through every day is a bit crazy - I get an email for every comment/issue on every Espruino repo, so I've now changed my notification settings for BangleApps to Participating and @mentions - so I won't get emails for literally everything that comes in any more.

I guess we'll see how it goes, but it looks like you've got it sorted - I'll try and keep up with PRs every week, but if you ever want me to look at something please just mention @gfwilliams

Hopefully I'll actually be more likely to respond to stuff - I think recently a few things have got lost in the general torrent of emails I end up sorting through each morning :)

thanks!

Good to know, thanks! 🙂

I was thinking about categorising the issues to see what's to be done at a glane and wanted to get some thoughts.

As I see it, issues are mostly divisible into these categories:

• Idea hatched, needs implementing
• Rough ideas, decision needed
• Uninvestigated

I was going to apply labels to the issues so we can see what might be stuck at the bottom, as opposed to the app writer (or one of us) fixing an app/lib. What do you all think?

Probably won't hurt, but you think that helps to get at least some of the issues closed? Skeptical.. unless someone just starts to work on one nothing happens.

Also from time to time I've looked through the issues, havn't found one I'm interested in (the rest got a comment and/or PR from me).

Thanks! Yes, if you think it'd help, go for it! I think you can create new labels just fine?

Obviously there are actual bugs, but i guess we tag issues with bug automatically. Maybe we should tag them with Uninvestigated instead, and then it's easy to find the ones that haven't been looked at yet?

Someone suggested a while back there's a good-first-issue tag (https://goodfirstissue.dev/) that we could add/use to tag things that we think someone new might be interesting in picking up. I don't know if that's worth it?

Other thoughts:

• Maybe we should tag issues that are bugs with the pre-installed/generic apps/libraries as I guess those take priority over ones on individual apps
• Is crash/similar a good tag? I guess actual crashes/lockups take priority over little glitches
• I think we should maybe consider idle 1+ month as a tag - I feel like for some of these issues, the issue was reported and then one of us asked a question and the reporter couldn't even be bothered to respond. Especially if it's something that couldn't be reproduced we should probably just mark it as idle and then 1 month later close it?

+1 to close if author does not respond in a certain time, but please do not close if requirements are clear and just not fixed.

Yeah, I'll see how things go - I don't want to rock the issues too much but I'll find the labels useful for searching for things to have a go at, and so on.

I've been through a couple and decided to label based on the issue's state, the area it's in (crash is a nice idea for this), and if it's an enhancement etc, whether it'd make a good first issue. I think bug/uninvestigated is a good idea too, I'll incorporate that in my next label-a-thon.

Yes - closing old issue is a good idea, but I agree, we should only do it if we can't make progress, rather than haven't

Thanks for your work on this - it really helps. Hopefully having a clearer set of issues will help potential contributors too - also, feel free to change the title of an issue if you think it isn't clear/helpful :)

My pleasure - all sorted. A few useful links:

• 🔇 Enhancements that have had no response from the author
• 🛠️ Hardware issues
• 📈 Bugs that've had some progress on them
• 👀 Good first issues
• 🧭 Issues we might decide on later

That's awesome - thanks for sorting though all of those! Looks like you really dug into a bunch of these issues - it must have taken hours!

You're welcome - it wasn't too long to be fair, gave me a good idea of old issues too