Add "Junior Jobs" and "Hero Wanted" tags to Issue list and Development Practice.

[Anonymouqs]

In Godot development, they were able to speed up releases with "Junior Jobs". Easy-to-fix issues would be tagged with "Junior Job" and instead of the advanced developers using their time on simple jobs, the simple jobs would be fixed by beginners.

"Hero Wanted" jobs show where the issue might be and how to fix it, but someone else does the "dirty work", (since the issue might not be exactly where the surface guess declares it is.) Hero Wanted jobs would be on the intermediate spectrum.

On the topic of "speeding up development", I think we need improve our image to attract more devs in by sending out more demos and having an "official" tutorial. Make great documentation not just about LMMS, but in DAW development as well and a wide variety of topics. The wiki is very outdated and needs a lot of work.

[tresf]

We already have Good first issue. We can rename it, but we need people to classify the hundreds of bugs we already have. This is a discussion for #devtalk on Discord. We do like user-engagement posts, but this topic has been discussed over and over.

by sending out more demos and having an "official" tutorial.

Like nightly and experimental builds? Yeah, we're working on that.

Make great documentation not just about LMMS, but in DAW development as well and a wide variety of topics.

@raindropsfromsky is updating our PDF as we speak. Perhaps you want to help write a new wiki for us? @Umcaruje was evaluating GitBook, talked about in #devtalk on Discord.

We invite help here. We don't turn away good work, or at least I hope we don't give that impression. We have a very active community and we share our beta builds with them when we have active development. We just don't have a lot of exciting features to test out right now.

[fundamental]

the simple jobs would be fixed by beginners.

This sort of labeling/mentality helps when there's a larger crowd of individuals contributing, but IMO for that label to be useful in the scope of a project like LMMS it needs to have more of a focus on obtaining new contributors and introducing new individuals to the codebase. Since you've made the godot comparison take a look at the pulse graphs for each. Over the last month LMMS has had 5 committers to the main repo (with 1 having more than a single commit) while godot has had 93 committers. That's not to say anything negative about LMMS, the projects are just at different scales, with different dev/user ratios, and they experience different organizational pressures. The dev/user ratio makes things particularly challenging IMO.

I personally like the idea of having a few "true beginner" sort of issues which really hold someone's hand through the entire process, but they're a large time investment which can be frustrating if it doesn't have success. For Zyn at least I likely won't write the details for a true beginner issue unless I know there's some level of interest from a specific individual. There's certainly no single factor which solves these sorts of problems (but if there is a sliver bullet say what it is, other FLOSS projects likely want to make contributions easier).

[Anonymouqs]

We just don't have a lot of exciting features to test out right now.

We have a lot of amazing and fun features to code(and documentation to fix might I add) yet we do not have the developers to code them:

1. We could code recording support
2. A more intuitive "pitch-bend" mode("instead of blindly aiming or doing some math we should be able directly "draw" the path with vector lines and whatnot on to the piano-roll)
3. Ability to send one channel to another, better vst support, and code refactoring so our program stays lightweight, yet powerful and doesn't crash. (You have to admit, for a game-engine, Godot is powerful for its file-size and CPU-usage)
4. We can change the workflow so its a lot easier. Node-mixing of some sort. Even video support!

The possibilities are endless.This program has already set a standard before; it can set the standard again, and then blow it out of the water a hundred-fold! With the support.

Our face on the internet is not the best that we can do. For example, our promo video is for 1.1, and we're at 1.3; some action needs to be taken. Arduor has overtaken us on the google search for "open-source DAW" (Although it forces users to pay up or go through a painfully long build process); some action needs to be taken. Some people don't know where to start with us; we need to put in a beginner section with a to-do list like in the documentation. Maybe some tutorials oriented to Sound Science that a 5-year-old can understand Yes, publicity will be a big investment, but by bringing in more developers and users to aid us, the reward outweighs the cost.

[tresf]

This isn't a competition. If you can offer something, please do. The pep rally is heartwarming, but the work remains. If there's specific action you need out of this bug report, just let us know. For example, if you are volunteering to go through the bugs and categorize, let us know so we can promote your access on the tracker. Reputation matters so showing us you've helped maintain a project (or making a PR with an improvement) will give us some comfort in granting access.

[fundamental]

we do not have the developers to code ....

I agree that this is a problem. For there to be FLOSS developers, there must (IMO) be a hook to get them interested, an onboarding process to make it easy for their work be integrated, and some organization to help them continue to contribute once they've broken the ice. Open source should be fun for contributors IMO.

It looks like you agree with some of the initial process.

• "[reputation] on the internet is not the best" -> getting initial interest
• "beginner section with a to-do list" -> make the onboarding process easier for that first contribution

When it comes to getting these sorts of things done there's the planning of what sorts of strategies might work and the execution of them. I personally find discussions very helpful for deciding what should be a priority as well as taking a task and breaking it into smaller actionable tasks.

For example with the original topic "Good first issue" labels within the issue tracker are present, but they might not currently be having much effect:

• Why would you have that impression?
• What sort of changes could be made?
• Who would have to make them?
• How would the changes be publicized to gain interest?
• What other related problems are there? e.g. if you increase the detail for each "Good first issue", then are you repeating yourself? If you're repeating yourself, then are issue templates beneficial? A common doc in the wiki or elsewhere?
• Who would be testing the new ideas? (i.e. possible new contributors)
• How would you get feedback about the process?

At the end of figuring out the answer to these sorts of questions you may end up with:

• "XXX writes a better description for issue alpha"
• "XXX writes a better description for issue beta...gamma"
• "YYY creates a link on the website's contributing guide to the labeled issues"
• "ZZZ and XXX tries to get interest from ABC"
• "ZZZ updates doc D if XXX has problems writing the description" etc

Realistically for a smaller open source dev team XXX/YYY/ZZZ are all going to be the person who proposed some work as they're likely the most interested and involved in it.

[Anonymouqs]

This isn't a competition. If you can offer something, please do.

I really want to help with the coding, but I'm still learning how to code in C++ and use QT. Just this Sunday, I built my first program from source-code on Windows(I feel like I passed into some sort of "technological manhood"... or puberty.) Currently, my strong suit is with markup languages, so for now, I'll be helping out with the docs.

For example with the original topic "Good first issue" labels within the issue tracker are present, but they might not currently be having much effect

I think Junior Job would be a better title which might eventually become a convention among open-source projects, or we could at least explain what "Good First Issue" means in the Get Involved area of the website.

On publicity, we just really need to make a good ruckus. A real shiny one that looks polished and refined. We've had users who have been commercially successful, we need to have them speak out. We also need to have a wide user base. The "best of LMMS" tracks aren't enough. We need to do comparisons with other programs (maybe after we have a chance of just being equal with them. Maybe a youtube channel! We can make a really awesome community with this, one that is closer than ever. We can even work with Ardour to add recording capabilities so more artists will be willing to use LMMS. (Please note that Ardour's weak-spot is our specialty, MIDI compositions) We can do this, the hill may be steep, but there's a peak. We'll gain momentum and never stop. But the dominoes must start somewhere. (And that's called this moment right now.)

[fundamental]

explain what "Good First Issue" means

Perhaps a small amount, but this is a standard tag across github. So, "good first issue" is already a convention.

maybe after we have a chance of just being equal with them

That's circular. You seem to be implying that we need Dev hours to reach feature parity before being able to attract devs.

We can even work with Ardour

How/Why/Who? Enthusiasm is fine, though to make real progress people need concrete things to work on.

[Anonymouqs]

"good first issue" is already a convention.

My bad, I'm new to open-source development. My specialty is in writing stuff. Speaking of confusion, I think we should at least explain to newbies on the Get Involved page what that means because I literally thought it was just a really well-typed issue by a new guy :P

That's circular. You seem to be implying that we need Dev hours to reach feature parity before being able to attract devs.

I meant in the far future. To attract even more devs and gain even more reputation once we have are notorious for being epic. I was just typing random ideas that came up, I really want to see this project grow. My teacher always said that you can still use a bad idea by turning it into a good one so I put out every idea that I have in discussions like these and hope someone might be able to use it :)

On Arduor, it's another open DAW that's getting famous, but its binaries aren't free and building it is torture (just scroll down to see the huge build stack.) Again, it's specialized in recorded music, but it isn't too good at MIDI(at least in reviews, maybe the newer editions are better). Collab can mean taking some of their code or even interacting with their devs.

One more idea: A blog.

[fundamental]

This thread is getting off-topic...

building it is torture

I strongly disagree. After building other Linux Audio software on my computer, building ardour was darn near trivial. Building large software projects on windows and to a lesser extent on OSX can be difficult, but ardour doesn't contribute to the platform dependent complexity IMO.

[Anonymouqs]

This thread is getting off-topic...

Back to the general topic then: How can we attract more developers and supporters to LMMS in order to speed up development?

[tresf]

Back to the general topic then: How can we attract more developers and supporters to LMMS in order to speed up development?

I suggest you read: https://github.com/LMMS/lmms/issues/3483, https://github.com/LMMS/lmms/issues/2745, https://github.com/LMMS/lmms/issues/3447

Attracting developers is a recruitment and marketing strategy but one (as @fundamental has explained) comes with a promise of invested time, something we're quite short on currently.

Instead of asking what can "we" do, perhaps a better question is what can "you" (or any one individual) do. We welcome help, but talking about it quickly grows tiring when we're short handed on volunteers.

To give you some scope on action items... rewriting the compiling tutorial (a precursor to #3483) took about a week to accomplish. I received feedback along the way, but the current version was solely written by me (some parts were adapted from our old tutorial).

Completing that ticket has grown tiring because one major strategy that I'm using to gain involvement is making our build system accessible in Windows, which has turned into a code cleanup effort followed by a package management and continous-integration task effort. But even clean-up has its caveats, such as making the build system harder for a beginner. Furthermore, the Qt5 framework comes in several deliveries so wrangling them all into a cmake build system is a doozie. This is what I'm doing to make more developers get engaged. Others may simply help test pull requests or confirm and clarify bugs. Many of our developers simply spend time developing by fixing stuff: e.g. helping [engage new developers] by-example.

Furthermore, we try to ask everyone that shows interest on Discord to consider helping with our bug tracker. We've gotten a few newcomers such as this guy -- but despite our efforts -- the efforts haven't brought in a lot of reinforcement. Most of it just shows up rather randomly. So to accommodate, we do offer a communication channel directly to the developers when they need assistance. I think we're covering our bases very well but we're open to more action (please, volunteer it as action, not simply as an idea, we're all full of ideas!)

[raindropsfromsky]

Tres,

I do understand that we have plenty of ideas about GUI design and features. But we do not have enough coders. So when a newcomer piles on a bucketful of more ideas, having to explain all this becomes a frustrating experience. Worse, the newcomer in his enthusiasm may end up arguing and press a few frayed nerves.

This can be avoided with a few low-effort tasks:

1. Explain the "idea/resource" situation in a couple of "welcome" web pages. Repeat this same explanation in ALL kinds of entries into LMMS world: Website, forum, Discord....

2. Provide a road map, with approximate timeline for clusters of features. By default, all features would start with "TBD" (to be decied) date.

3. If you need help with specific skills, list them at the website. Let people volunteer.

4. Also publish your own wish list for tasks like re-designing the website, forum etc. Mention the specific skill-sets you need, so that people can volunteer.

5. Can we have a LMMS annual festival where users get to select one favorite feature they want ahead of others Or couple this with a music competition: The winner gets to select his ONE favorite feature.

6. Can we have some sort of skill-level scale in music-makers? (e.g. newbie, Intermediate, Advanced, Master) This scale can be self-declared. The idea is that the less-skilled members get guidance/mentorship from the more skilled fellows.

7. Finally what do you need from me? Apart from the pdf file, I can make videos, with Closed Captions and TTS-generated voice-over in all major languages. So if translators are available, we can make the same dubbed video for all major markets.

8. Maintain a highly visible list of volunteers who are working on any project. That will motivate the others to join the effort.

On Fri, Feb 23, 2018 at 1:41 AM, Tres Finocchiaro notifications@github.com wrote:

Back to the general topic then: How can we attract more developers and supporters to LMMS in order to speed up development?

I suggest you read: #3483 https://github.com/LMMS/lmms/issues/3483,

2745 https://github.com/LMMS/lmms/issues/2745, #3447

https://github.com/LMMS/lmms/issues/3447

Attracting developers is a recruitment and marketing strategy but one (as @fundamental https://github.com/fundamental has explained) comes with a promise of invested time, something we're quite short on currently.

Instead of asking what can "we" do, perhaps a better question is what can "you" (or any one individual) do. We welcome help, but talking about it quickly grows tiring when we're short handed on volunteers.

To give you some scope on action items... rewriting the compiling tutorial (a precursor to #3483 https://github.com/LMMS/lmms/issues/3483) took about a week to accomplish. I received feedback along the way, but the current version was solely written by me (some parts were adapted from our old tutorial).

Completing that ticket has grown tiring because one major strategy that I'm using to gain involvement is making our build system accessible in Windows, which has turned into a code cleanup https://github.com/LMMS/lmms/pull/4000 effort followed by a package management https://github.com/lukesampson/scoop-extras/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Atresf+ and continous-integration task https://github.com/LMMS/lmms/compare/master...tresf:appveyor effort. But even clean-up has it's caveats https://github.com/LMMS/lmms/pull/3957#issue-151298687, such as making the build system harder for a beginner. Furthermore, the Qt5 framework comes in several deliveries so wrangling them all into a cmake build system https://github.com/LMMS/lmms/pull/4067 is a doozie. This is what I'm doing to make more developers get engaged.

Furthermore, we try to ask everyone that shows interest on Discord https://lmms.io/chat to consider helping with our bug tracker. We've gotten a few newcomers such as this guy https://github.com/LMMS/lmms/pull/3947, but the efforts haven't brought in a lot of reinforcement. We do offer a communication channel directly to the developers when they need assistance though. I think we're covering our bases very well but we're open to more action (please, volunteer it as action, not simply as an idea, we're all full of ideas!)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/4182#issuecomment-367806948, or mute the thread https://github.com/notifications/unsubscribe-auth/AIoMgIO5WZlA63G0jDi50oNBSYnsk5mNks5tXcoHgaJpZM4SOAMx .

[fundamental]

1 Explain the "idea/resource" situation in a couple of "welcome" web pages.

How do you word that bluntly enough that new users encounter the text and understand it without it sounding like "we don't have resources, the project is semi-dead"?

2 Provide a road map, with approximate timeline for clusters of features.

What level of granularity would be present? I've seen this sort of suggestion elsewhere (not-LMMS related), but the major problem is that it's nearly impossible to estimate a specific date unless there's at least one person actively working on the particular roadmap item currently.

4. Also publish your own wish list for tasks like re-designing the website, forum etc.

Having a wish list is a good thing, though I'd be careful about publishing it as it could create unrealistic expectations which are known to be an issue.

5. Can we have a LMMS annual festival where users get to select one favorite feature they want ahead of others

If going this route, then the selection of options needs to be limited to well vetted ideas with a solid plan on how to go about adding the feature. Otherwise this will create the expectation that the functionality will appear soon even if there's a ton of work left to be done.

3, 8

+1

[tresf]

3. If you need help with specific skills, list them at the website. Let people volunteer.

And this is why we can't have nice things. 🙄. Seriously, @raindropsfromsky we do! https://lmms.io/get-involved/. If you want to make this clearer, please issue a PR against the page here: https://github.com/LMMS/lmms.io/blob/master/templates/get-involved.twig. Getting involved isn't hard. @Anonymouqs thanks for the PR, BTW!. This is exactly what we need. (https://github.com/LMMS/lmms/pull/4184 for reference).

8. Maintain a highly visible list of volunteers who are working on any project. That will motivate the others to join the effort.

We haven't built developer profiles yet. We should and this is a nice marketing effort but it takes a while to collect (and format) the the bios. I welcome anyone to perform this effort. The fastest way to collect names is to click through the commit logs. Many people make their github profiles public and that's a good start. Here's a start for someone that can help build this for us (I've just typed a few, I'd be happy to answer any detailed questions on Discord).

Edit: Added project maintainers page: https://github.com/LMMS/lmms/wiki/Project-Maintainers

[fundamental]

@tresf Perhaps I'm misreading point 3, but my interpretation was to list specific skills/keywords Qt, C++, french translations, audio DSP, etc with a focus on the easier end of the spectrum. There's a reasonable number of eyes looking at a project like LMMS, it's a matter of selling the idea of contributions. One approach is to say "We need this skill that you have" and being specific can help with the message coming across as a targeted "you" rather than a more generic "anyone" (which can result in a tragedy of the commons sort of situation).

As per the exact semantics of how to do this, I don't know.

[tresf]

@fundamental perhaps I need to be more inviting with the branding side of things, but for those wanting to help maintain this information, we invite you to. I think the resources above give everything needed to get started. I am NOT volunteering to maintain yet another constantly changing portion of our software for speculative gain, but I'd be happy to answer questions.

[Anonymouqs]

We need to advertise that we need to advertise to circles outside of LMMS far and wide.

What I eventually want to do is create a tutorial of DAW programming based on LMMS, so once people finish it, they can be confident with programming for LMMS.

For now, I'm still learning QT and C++ programming since it is immensely different from the glorious Python Master Race ;D

[fundamental]

We need to advertise that we need to advertise to circles outside of LMMS far and wide.

Specifically who? What individuals? What organizations? What websites? What type of content? etc. Specifics are needed otherwise it's just throwing ideas into an abyss.

For now, I'm still learning QT and C++ programming

If you want to write tutorials you're in an interesting spot as the problems you are encountering are likely the same problems other beginners are encountering (or will encounter in the future). Take notes, write documentation, and try to get others to fact-check you if you're not sure.

[tresf]

If you want to write tutorials you're in an interesting spot as the problems you are encountering are likely the same problems other beginners are encountering (or will encounter in the future). Take notes, write documentation, and try to get others to fact-check you if you're not sure.

Whole heartedly agree. The best time to document is the first run. It spots common things that long-time devs have grown accustomed to.

[Anonymouqs]

Specifically who? What individuals? What organizations? What websites? What type of content? etc. Specifics are needed otherwise it's just throwing ideas into an abyss

Advertise on developer forums, music maker forums ect. Make a great blog We also need people to make even more awesome music with LMMS: I remember a long time ago there was a name of an artist who used LMMS and got a contract. I'll try to find his name in the docs. Maybe we could have him become a spokesperson for LMMS. Just as on how Martin Garrix uses FL. If you notice, Deadmau5 uses Ableton and he has a Master-Class, which obviously would advertise Ableton ever more.

[tresf]

This post started as "tag bugs better" and has turned into some mesh of "get more involved". It's a natural escalation, but it's gone terribly off-topic without resolve in the original question.

I'll say this again, if you (or anyone else) is willing to help categorize our 600+ bugs, we'll grant you the appropriate access and then close this task once completed.

We can then try to boost developer engagement by sending these quick fixes to the wild. We could even put bounties on them (although my experience with sites like bountysource has been largely unsuccessful).

Furthermore, if you are volunteering yourself for the promotional tasks, let's identify what you're going to do and make sure you have the blessing from the rest of the team. If you're not volunteering, then we may want to properly milestone them for when someone is available. Probably best done in a separate conversation, perhaps here on GitHub, perhaps in Discord, but let's not make yet another endless thread out of it.

I say this because when you bring up the conversation about pros, commercial DAWs, marketing, there's so much room for opinion that it's truly endless if we don't put someone in charge.

Categorizing bugs on the other hand is quite black-and white. It's an investment of time combined with some knowledge of the complexities of the codebase.

[Anonymouqs]

@tresf I would be interested in categorizing bugs. I would be able to categorize the simple ones with ease. I'm still studying the code-base.

[tresf]

@Anonymouqs ok, I've put up a vote on Discord's #devtalk channel. Thanks for volunteering.

[tresf]

@Anonymouqs, you have the proper access to help categorize bugs, thanks for volunteering.

The usual disclaimer... This will give you access to a few other areas as well. Just ask before making any other huge sweeping changes, please. Discord is the best place. https://lmms.io/chat

We need all the help we can get!

[tresf]

Original bug report:

• @Anonymouqs you have access to create tags and classify bugs. I see you've been doing this, so this bug report can be closed.

Other items:

• The "contributors" page... I did the heavy lifting here: https://github.com/LMMS/lmms/issues/4182#issuecomment-368061576. Create it and get on with it please.
• All the features you listed (pitch bend, recording) are futuremap stuff. Please use #4197 for that. @BaraMGB showed interest in this as well. Let's get it published, but it's a duplicate here and worse, it'll get buried.
• Promo vid for 1.2, 1.3: Volunteers welcome. Let's bring that to https://github.com/lmms/lmms.io repo though, that's where we handle that stuff.
• "We need to do comparisons with other programs" - I vote no for this but if you want to make a comparison page we can consider putting it on our home page. I guess you could compare us to similar but different products like Audacity. It would help people understand LMMS' place for a DAW. I recommend you file a new bug over at https://github.com/lmms/lmms.io for this if you really plan on doing it.
• "Advertise on developer forums, music maker forums ect" - KVR has asked us to keep our LMMS page on their site up to date better. Someone can run with this. Perhaps we add a checklist on where we send communication on each release. Currently, @Umcaruje and I do the releases by ourselves -- usually requires some decisions on bugs and stuff. So, we're not looking for more work. If you want to run with this, document the things we should do with each release. We can use the wiki over at https://github.com/lmms/lmms.io I guess. I'd hate to bulk the wiki here with it.

Hopefully that covers all of the reading material above. Please organize these thoughts and close @Anonymouqs. Many of the conversation points have merit, but seem to be over.

[tresf]

• Project maintainers page added here: https://github.com/LMMS/lmms/wiki/Project-Maintainers.
• "Good first issue" is alive and well now, please check it out for bugs to get started with!
• "Hero wanted" is perfectly welcomed but is out of scope until we can organize the tracker up a bit more.

Closing as the conversation seems to be over. Feel free to chime in and/or request reopen as needed.