User talk:Duggabe: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
No edit summary
(Initial creation)
 
(26 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=Tech writing presentation=
== Analysis of Zammad helpdesk software ==


This is a DRAFT.
Our intended use of the Zammad software is to handle all emails received by <code>grcon@gnuradio.org</code>, <code>tickets@gnuradio.org</code>, and <code>sponsor@gnuradio.org</code>. It assigns a ticket number to each initial customer interaction and tracks the progress of the response, keeping subsequent emails within the same ticket as a "thread".


==Preparation==
=== Configuration and Use ===
* GNU Radio Main Page
    https://wiki.gnuradio.org/index.php/Main_Page
* A Newbie's Guide to the GNU Radio Universe
    https://www.youtube.com/watch?v=uxAW-WzuNy0


==Background==
==== Overview Selection Panel ====
* Amateur radio operator since 1953
* Electrical Engineering degree 1961
* Computer programmer since 1962
* Retired 2003
* Started working on GNU Radio 2019


==What is GNU Radio==
The area of the Overviews screen which selects what emails to display currently combines four different filters into one:
GNU Radio is a free and open-source software development toolkit that provides Digital Signal Processing blocks to implement Software Defined Radios. It is an entirely volunteer organization with contributors from all over the world.
* Email source (grcon, tickets, or sponsor)
* STATE (new, open, closed, pending)
* All
* Assigned to me


==Why did I get involved?==
This leads to at least 14 selections. This is not ideal (in my opinion), but can be used for initial trials. A better solution would be to have two or three dropdown menus to do the selection (or maybe Github issues selection style).
I discovered GNU Radio when reading an amateur radio manual. I thought it was a fascinating concept to use software instead of hardware to create a radio. After reading the "discuss-gnuradio" mailing list for a while, I noticed a recurring topic of "GNU Radio documentation is terrible". Looking at it, I had to agree, and decided to do something about it.


==Learn by Doing==
==== Tags ====
* When I got involved, the switch to using a Wiki was new. Many of the blocks were just skeletons with no real content. For example, https://wiki.gnuradio.org/index.php?title=Cvsd_encoder is yet to be documented after more than four years.
** I had to learn to use [https://www.mediawiki.org/wiki/MediaWiki MediaWiki].
** I had to learn what a block did before I could write about it!
** After the first year of working on them, I had done over 150 blocks and written or updated about 10 tutorials.


==Help others to Learn==
If Tags must be selected from a pre-defined list, more options need to be defined.
I have found that the best way to learn about a technical subject is to study a turorial about it. However, there were very few tutorials, and the ones which existed were out of date because of newer software releases of GNU Radio.


==Adopting a Style==
=== Success Requires Full Participation ===
It was rather surprising to me that there was no formal guidance for the style of the Block Docs or for tutorials. As I started working on the Block Docs, I derived a skeleton format which covered all of the items I found in various blocks. That gave a consistent layout from one block to the next. I also got some guidance from my mentor at GNU Radio based on unwritten expectations of how a block should be documented.


For the Tutorials, there was much more latitude to create / use my own style. My basic approach was to write for a beginner with only the Prerequisites as a background. Other than that, I used an "Assume nothing" approach.
For the Zammad software to work for us, every person who processes email for any of the sources (grcon, tickets, or sponsor) must have full read and write privileges, and <b>MUST USE ZAMMAD instead of direct access to the Gmail interface.</b> Mixing the two would lead to confusion and lack of coordination.


==Some examples==
=== Path Forward ===
One of my more popular tutorials is https://wiki.gnuradio.org/index.php?title=Simulation_example:_FSK Along with that, I wrote the Block Doc for the https://wiki.gnuradio.org/index.php?title=VCO which is the key block in generating the FSK signal.


In doing my work on the documentation, I wanted to make sure that what I wrote actually worked. So for each of my blocks and example flowgraphs, I created and tested them before I published them. For several of them, I created a complete working system using SDR hardware to operate with an amateur radio station. For example, https://github.com/duggabe/gr-RTTY-basics implements an amateur radioteletype station.
I propose that I be given 'admin' privileges to create a workable configuration for further testing and evaluation.

Latest revision as of 16:53, 19 February 2024

Analysis of Zammad helpdesk software

Our intended use of the Zammad software is to handle all emails received by grcon@gnuradio.org, tickets@gnuradio.org, and sponsor@gnuradio.org. It assigns a ticket number to each initial customer interaction and tracks the progress of the response, keeping subsequent emails within the same ticket as a "thread".

Configuration and Use

Overview Selection Panel

The area of the Overviews screen which selects what emails to display currently combines four different filters into one:

  • Email source (grcon, tickets, or sponsor)
  • STATE (new, open, closed, pending)
  • All
  • Assigned to me

This leads to at least 14 selections. This is not ideal (in my opinion), but can be used for initial trials. A better solution would be to have two or three dropdown menus to do the selection (or maybe Github issues selection style).

Tags

If Tags must be selected from a pre-defined list, more options need to be defined.

Success Requires Full Participation

For the Zammad software to work for us, every person who processes email for any of the sources (grcon, tickets, or sponsor) must have full read and write privileges, and MUST USE ZAMMAD instead of direct access to the Gmail interface. Mixing the two would lead to confusion and lack of coordination.

Path Forward

I propose that I be given 'admin' privileges to create a workable configuration for further testing and evaluation.