开云体育

Is it time to create a group managed d-rats.github.com project?

A group managed GitHub project will allow multiple community members to be the administrators of it similar to the [email protected] mailing list.

I have no idea how the groups.io d-rats group is managed, but it seems to work well enough, if they could also do the administration of the GitHub project.

This project would have multiple d-rats related repositories on it.

This could have one or more data repositories with urls or other data that could be downloaded from the d-rats program instead of being hard coded and sometimes out of date like the ratflector list.

The GTK 3 library wants to have the d-rats main be an "application" that has a unique application identification. They prefer to use reverse domain name notation, with a GitHub project that would be something like "com.github.d-rats.client".

The reason for adding the ".client" is because we may want the form editor to be able to be run as a standalone program, and the repeater is also a standalone program, so would have different application identifications.

73,
-John, wb8tyw

On 12/16/2021 9:46 AM, John E. Malmberg wrote:

Is it time to create a group managed d-rats.github.com project?
A group managed GitHub project will allow multiple community members to be the administrators of it similar to the [email protected] mailing list.
I have no idea how the groups.io d-rats group is managed, but it seems to work well enough, if they could also do the administration of the GitHub project.
This project would have multiple d-rats related repositories on it.
This could have one or more data repositories with urls or other data that could be downloaded from the d-rats program instead of being hard coded and sometimes out of date like the ratflector list.
The GTK 3 library wants to have the d-rats main be an "application" that has a unique application identification.?? They prefer to use reverse domain name notation, with a GitHub project that would be something like "com.github.d-rats.client".
The reason for adding the ".client" is because we may want the form editor to be able to be run as a standalone program, and the repeater is also a standalone program, so would have different application identifications.
73,
-John, wb8tyw

This would be an organization setup:



73,
-John

Reference Link:



On 12/17/2021 2:05 AM, Maurizio Andreotti wrote:

HI John,
(reminding that i am not english-.language native and maybe i could be a
bit direct here)
I think that this could be a good idea,
in the "group managed github", group is the key point : i mean the group
should be a group of people and someone with really strong programming
skills and social skills should lead it.

Obviously I think that you should be an administrator of this new "D-RATS GitHub Organization"

I think we need more than two people to be administrators of the organization, and that why I would suggest the managers of the groups.io mailing list would be a good choice for that.

I want to avoid the GitHub Organization being in a orphan state because one or two key people are no longer able to contribute.

Looking back at my experience with D-Rats i think that not being a
professional programmer (better. not even a programmer at all) I wasn't
able to attract the support needed to take D-Rats to overcome the speed
needed to cope with the evolution of the undelying evolutions.

The problem is that there is a general world-wide shortage of people with the skills to do this type of work, and in many cases those people are just too busy.

I am a professional programmer. D-Rats is not the type of programming that I do professionally though. Python is something that I have learned on the job as different programming languages go in and out out style.

Free training is available on the web for python. The quality for GTK-3/4 is not as good as I would like though, and most of the links are either for GTK-2, are dead, or people asking for help for the same thing I was looking for and getting no answers.

But we can help each other with self training.
Example:

I am willing to try the time to help people that have the time and want to learn something new. Take some working code, try a tweak, and see that happens.

It takes longer, but I am trying to document what I am doing to solve issues that I have had to figure out.

And working on an open source project like this can count toward professional experience for a future job. My current employment is mainly based on skills learned by working on open source hobby projects.

MacOs compatibility was lost on the way, compatibility with python 2
libraries getting loose, linux support for py2 the same, issues on ms
windows performances, maps issues, weather integration, lack of
implementation of the new icom data burst transmission...

I do not have access to a Mac to do the testing. To support a platform,
we mainly need volunteers with that platform willing to do the tests and
give feedback. Even better if they can tell us what code changes are needed.

It looks like the Mac support code is still present, so I am not sure what does not work.

Off course with the help of all (Marius in primis) and really long hours of
my time (as not a programmer i need to trial and error a lot of things
which just should be straightforward) we skipped to declare d-rats death,
but it is a situation which do not permit much evolutions

Trying to turn into positive mood, let me ask to all people reading this
email:
who is in and with committment?

Obviously I am in for this.

It is slightly different from running an individual GitHub project. There are additional controls:

Generally these roles exist, and these type of roles can be global to the Github organization project and also can be local to a repository.

We probably want as simple of an organization as possible.

1. Administrators. They allow group members to join and to be assigned roles. These people do not need programming skill, but do need to be able to determine what roles that someone can have.

2. Gatekeepers. The Gatekeepers for a repository are people who can permit a merge into a production branch. This can be a technical role, but it can also be one where you take into account the advice of other developers and testers.

3. Contributors. These are people that are allowed to create branches, in repositories, but may not be allowed to merge in to production branches. We may or may not need to formally populate this role.
Especially if contributors are using private forks, and submitting PRs.

4. Reviewers, people available to review or test the code.
By having them members of the project it is easy to

73,
-John