Grant Ideas: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
No edit summary
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
Similar to the [GSoC Ideas|GSoCIdeas] page, this is a list of things we could potentially ask for grant money to accomplish, or even just volunteers who want something specific to dive into:
Similar to the [[GSoCIdeas|GSoC Ideas]] page, this is a list of things we could potentially ask for grant money to accomplish, or even just volunteers who want something specific to dive into:
 
== Documentation Related ==
 
=== Doxygen Cleanup ===
 
We recently moved all usage-style docs to the wiki, including the one-page-per-block docs, and it's been going great, but one problem is that the Doxygen still contains the block usage docs that we used as a starting point for the wiki, and I (Marc) think we should strip all of that out of the Doxygen and only leave stuff that is developer-centric, like useful for anyone looking at (or modifying) the code.  Now one question that would need to be answered is how deep we go with the list of params for each block, like do we just list the params with no description in Doxygen and refer to the wiki page for the block?  We want to avoid information living in two places. 
 
=== More Tutorials! ===
 
Barry has been rocking it with the tutorials but we can always use more, or have more advanced ones cleaned up
 
=== Filling out Block Docs ===
 
There are still plenty of blocks without proper documentation, whether that's the description of each param, or examples, although one problem is we dont all have expert knowledge about every block, so there might need to be some reaching out to experts to try to data mine info that can be put into the docs.  People tend to be more willing to write an email explaining how some block or param works, if it means they dont have to actually write the docs themselves.
 
=== Coming up with a system for exporting and versioning wiki ===
 
Now that tons of our docs live on the wiki, it opens up the question of how we can tie docs to versions of GR, and what people who dont have internet access do.  These two problems can probably be solved together, because if there was a nice export of the wiki (e.g. block docs, tutorials, usage manual) then we can do an export each time a release is created, and host it somewhere.  But it brings up the issue of all the changes we back-port into the older releases... So we need to decide how big an issue that is.  There might also be a wiki plugin/extension that can help us do better versioning.  Brainstorming is needed, and whatever approach we decide needs to be agreed on by the majority.
 
== Training Materials Related (Not including tutorials in our docs) ==
 
In the past GNU Radio training sessions were provided by the project leads, both in-person and remote, which usually includes powerpoints and exercises.  Derek is currently working on creating beginner level training materials, but we could always use more money/effort to create more advanced or specific to some area like radio astronomy or spectrum sensing or something.  This one would be pretty easy to explain in a grant proposal, because the deliverable is very straightforward and its easy to explain why creating such training material is so important for the scientific/research community, GNU Radio has such a high learning curve after all.
 
== Packaging ==
 
=== Windows & OS X Packaging ===
 
Pay someone to maintain Windows or macOS packaging, e.g. 20 hours a month or something and ideally it would be long term, 1+ years.
 
=== CI-generated Packages ===
 
Maintaining a Linux (e.g. Ubuntu) package repository is a lot of work, and ideally, we'd do it for more than one distro. We might pay someone who sets everything up, so that CI triggers (automatically) a regular generation of packages, and can be instructed to generate new release packages. In a perfect world, that person would accompany the project for the duration of ~2 releases, so that the kinks are worked out with a high probability.
 
=== Maintainer Assistance ===
Pay someone to assist the lead maintainer, by going through issues and PRs to try to label and weed out stuff, and just do whatever they can manage to help reduce the lead maintainers work load.  Martin had some good words to describe this kind of role, and it's extremely valuable and would be worth paying for if we found the right person.
 
== GNU Radio 4.0 and Beyond ==
 
There is amazing work going on in the newsched working group, its really paving the way for the next generation GNU Radio, and if we were to find the right person and pay them with a grant, they could really dive in and help move things along, perhaps spend time benchmarking and creating QA code, or creating documentation, etc.  Just to try to take some of the load off the folks already working on it.  We just need to be tactful about what we pay someone to do, we don't want the volunteers to feel weird about it, so the best bet is to carve out a very specific piece of work that no one else is currently working on.

Revision as of 07:05, 20 August 2021

Similar to the GSoC Ideas page, this is a list of things we could potentially ask for grant money to accomplish, or even just volunteers who want something specific to dive into:

Documentation Related

Doxygen Cleanup

We recently moved all usage-style docs to the wiki, including the one-page-per-block docs, and it's been going great, but one problem is that the Doxygen still contains the block usage docs that we used as a starting point for the wiki, and I (Marc) think we should strip all of that out of the Doxygen and only leave stuff that is developer-centric, like useful for anyone looking at (or modifying) the code. Now one question that would need to be answered is how deep we go with the list of params for each block, like do we just list the params with no description in Doxygen and refer to the wiki page for the block? We want to avoid information living in two places.

More Tutorials!

Barry has been rocking it with the tutorials but we can always use more, or have more advanced ones cleaned up

Filling out Block Docs

There are still plenty of blocks without proper documentation, whether that's the description of each param, or examples, although one problem is we dont all have expert knowledge about every block, so there might need to be some reaching out to experts to try to data mine info that can be put into the docs. People tend to be more willing to write an email explaining how some block or param works, if it means they dont have to actually write the docs themselves.

Coming up with a system for exporting and versioning wiki

Now that tons of our docs live on the wiki, it opens up the question of how we can tie docs to versions of GR, and what people who dont have internet access do. These two problems can probably be solved together, because if there was a nice export of the wiki (e.g. block docs, tutorials, usage manual) then we can do an export each time a release is created, and host it somewhere. But it brings up the issue of all the changes we back-port into the older releases... So we need to decide how big an issue that is. There might also be a wiki plugin/extension that can help us do better versioning. Brainstorming is needed, and whatever approach we decide needs to be agreed on by the majority.

Training Materials Related (Not including tutorials in our docs)

In the past GNU Radio training sessions were provided by the project leads, both in-person and remote, which usually includes powerpoints and exercises. Derek is currently working on creating beginner level training materials, but we could always use more money/effort to create more advanced or specific to some area like radio astronomy or spectrum sensing or something. This one would be pretty easy to explain in a grant proposal, because the deliverable is very straightforward and its easy to explain why creating such training material is so important for the scientific/research community, GNU Radio has such a high learning curve after all.

Packaging

Windows & OS X Packaging

Pay someone to maintain Windows or macOS packaging, e.g. 20 hours a month or something and ideally it would be long term, 1+ years.

CI-generated Packages

Maintaining a Linux (e.g. Ubuntu) package repository is a lot of work, and ideally, we'd do it for more than one distro. We might pay someone who sets everything up, so that CI triggers (automatically) a regular generation of packages, and can be instructed to generate new release packages. In a perfect world, that person would accompany the project for the duration of ~2 releases, so that the kinks are worked out with a high probability.

Maintainer Assistance

Pay someone to assist the lead maintainer, by going through issues and PRs to try to label and weed out stuff, and just do whatever they can manage to help reduce the lead maintainers work load. Martin had some good words to describe this kind of role, and it's extremely valuable and would be worth paying for if we found the right person.

GNU Radio 4.0 and Beyond

There is amazing work going on in the newsched working group, its really paving the way for the next generation GNU Radio, and if we were to find the right person and pay them with a grant, they could really dive in and help move things along, perhaps spend time benchmarking and creating QA code, or creating documentation, etc. Just to try to take some of the load off the folks already working on it. We just need to be tactful about what we pay someone to do, we don't want the volunteers to feel weird about it, so the best bet is to carve out a very specific piece of work that no one else is currently working on.