Add "Junior Jobs" and "Hero Wanted" tags to Issue list and Development Practice. #4182
Comments
|
We already have
Like nightly and experimental builds? Yeah, we're working on that.
@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. |
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). |
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:
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. |
|
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. |
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.
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:
At the end of figuring out the answer to these sorts of questions you may end up with:
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. |
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.
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.) |
Perhaps a small amount, but this is a standard tag across github. So, "good first issue" is already a convention.
That's circular. You seem to be implying that we need Dev hours to reach feature parity before being able to attract devs.
How/Why/Who? Enthusiasm is fine, though to make real progress people need concrete things to work on. |
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
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. |
|
This thread is getting off-topic...
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. |
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, #2745, #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 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!) |
|
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 ***@***.***> 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 <#3483>,
#2745 <#2745>, #3447
<#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 <#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
<#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
<master...tresf:appveyor> effort.
But even clean-up has it's caveats
<#3957 (comment)>, 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 <#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
<#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
<#4182 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIoMgIO5WZlA63G0jDi50oNBSYnsk5mNks5tXcoHgaJpZM4SOAMx>
.
|
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"?
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.
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.
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.
+1 |
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. (#4184 for reference).
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 |
|
@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. |
|
@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. |
|
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 |
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.
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. |
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. |
|
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. |
|
@tresf |
|
@Anonymouqs ok, I've put up a vote on Discord's #devtalk channel. Thanks for volunteering. |
|
@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! |
|
Original bug report:
Other items:
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. |
Closing as the conversation seems to be over. Feel free to chime in and/or request reopen as needed. |
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.
The text was updated successfully, but these errors were encountered: