Extend GitHub features usage (ie Labels, Projects, Milestones, Discussions, Wiki)

[silopolis]

Hello friends,

Coming back from family holidays and after too many weeks pulled away by work issues, even if I did my best to keep track of all the great work that's been done in the meanwhile, I wish we had a little more structured organization to more easily:

• Get a clearer overview of LinuxCNC project status than a flat, unlabelled list of issues
• Use Projects and Milestones to manage and keep track of our "initiatives" (Debian integration, po4a migration, 2.9 release...)
• Support and log our long running Discussions (that are today scattered in many issues) and prepare meetings
• Use Wiki to support all the above for documentation and more structured information gathering

For those who'd like to get a glimpse of all this, you can check my playground here (just ask for rights if you want to play too):

• https://github.com/silopolis/linuxcnc/projects
• https://github.com/silopolis/linuxcnc/milestones
• https://github.com/silopolis/linuxcnc/discussions
• https://github.com/silopolis/linuxcnc/wiki

I believe these tools could be helpful to our project in many ways. I know managing all this would be additional work, but as I myself feel the need for these features, I'd be willing to set them up for the community.

My plan would be to start by using these features to plan and manage their own deployment:

• A project would be created to manage this deployment
• A milestone would be created to track progress
• Seminal Discussions would be created about:
  • Labels taxonomy(ies) and usage
  • Projects and Milestones usage
  • Discussion usage
  • GH wiki usage, with or vs current wiki
• Once some kind of consensus on each matter would be reached:
  • it would be summed up in its own Wiki page About wiki pages, each could be linked
  • Resulting Labels, Projects, Milestones, Issues, Discussions and Wiki pages would be progressively created

Looking forward to reading from you friends

J

[petterreinholdtsen]

[Jérémie Tarot]

Hello friends,

Welcome back.

While I recognize many good ideas in your vision for a more structured project, I suspect it will raise the bar of contribution and imcrease the administrative work load for everyone involved above the level we can sustain. So far we have enough organizing a video chat once a month, and very few of the people involve3d are exchanging messages on IRC regularly. Starting with canban boards and milestones seem completely out of reach to me at the moment.

I suggest we continue the effort to meet regularly, and once that is working well, we can see what other formalities we want to introduce.

But of course, if you are up to handle the overhead involved, we might be able to pull it off.

-- Happy hacking Petter Reinholdtsen

[silopolis]

Le mar. 23 août 2022 à 13:43, petterreinholdtsen @.***> a écrit :

[Jérémie Tarot]

Hello friends,

Welcome back.

Slowly but surely 😉

While I recognize many good ideas in your vision for a more structured

project,

Glad you do :)

I suspect it will raise the bar of contribution and imcrease

the administrative work load for everyone involved above the level we can sustain.

I believe the a good part should not be that much while potentially bringing the most benefits, like proper issues labelling, gathering issues in milestones, having dev related discussions in a dedicated and lightly structured place. For proper project management, well, we'll see...

So far we have enough organizing a video chat once a

month,

This is actually one of the things making me thinks we could benefit from this at low cost. Having a dedicated Discussion before to drop ideas and questions, and a wiki page after for minutes doesn't differ much from email threads and google doc we use today, just easier to find and follow for people new or less involved in the project.

and very few of the people involve3d are exchanging messages on

IRC regularly.

I also hope this would bring more clearness and "readability" to the project to attract new comers and hopefully revive others...

Starting with canban boards and milestones seem

completely out of reach to me at the moment.

Milestones are really just a bunch of issues grouped together to track progress. Due date is not even mandatory. But as an example, it would set clear what's on our plate for 2.9... Or at least force us to do so!

I suggest we continue the effort to meet regularly,

Sure, at any price!

But of course, if you are up to handle the overhead involved, we might

be able to pull it off.

I'd like to give it a try, yes.

[c-morley]

(comment from #1899) I seems you are using milestones differently then I mean.

Milestones are really just a bunch of issues grouped together to track progress. Due date is not even mandatory.

When I said milestone I meant a date. Milestones without dates are not very effective.

You guys are talking way ahead of what we need to start with. And that's ok, forward thinking is good. But: We still haven't picked an official date for 2.9 (aside from 'in weeks' and 'this year') We still don't even have a 2.9 branch to actually work on. We seem to think it's a good idea to stabilize our development branch for release - in the development branch. We don't even use the mail list effectively, using github is a higher bar.

Maybe we should discus what the project needs to grow devs and users. Some policy discussions -such as merging released branches is silly and a roadblock.

Some if using github can facilitate this then sure, but so can email.

[silopolis]

Le ven. 26 août 2022 à 03:25, c-morley @.***> a écrit :

(comment from #1899 https://github.com/LinuxCNC/linuxcnc/pull/1899) I seems you are using milestones differently then I mean.

Milestones are really just a bunch of issues grouped together to track progress. Due date is not even mandatory.

When I said milestone I meant a date. Milestones without dates are not very effective.

Well, I believe we're just talking about two different use cases or stages in the life of a milestone. There can be "feature" milestones (somehow issues groups w/o dates) tracking work progress of development until completion on one hand, and "planning" milestones with due dates indeed. But I tend to see this as two stages in the milestone lifecycle where it starts as a feature/goal milestone, used to gather issues related to it offering, compared to a simple label:

• An overview page of the current endeavours
• A description with possibility to add a link to the corresponding project
• A nice progress "widget"

You guys are talking way ahead of what we need to start with. And that's

ok, forward thinking is good. But: We still haven't picked an official date for 2.9 (aside from 'in weeks' and 'this year') We still don't even have a 2.9 branch to actually work on.

As @petterreinholdtsen pointed in https://github.com/LinuxCNC/linuxcnc/pull/1657#issuecomment-1227028352, and as we're having hard time setting release date, we could either decide:

• to release 2.9 by the end of january to have it ready for Debian soft freeze, giving us time more time for a point release just before Bookworm release for an ironed LinuxCNC in future Debian stable; this of course implies anticipating creation of the 2.9 release branch, which in turn needs to define what's to be done before that, ie a feature freeze goal..., or *to sync release with Debian, create 2.9 branch just before Debian soft freeze, and then follow Debian's release planning

We seem to think it's a good idea to stabilize our development branch for release - in the development branch.

I too hope (and still believe;) ) we don't, but current work can be misleading as it's mostly made of clearing pending issues and fixing build, packaging and translation bugs...

We don't even use the mail list effectively, using github is a higher bar.

Agreed we could squeeze more out of ML, but I believe it requires more discipline than GH tools

Maybe we should discus what the project needs to grow devs and users.

You'd just had to drop it in the next meeting discussion to have it easily filed in a nice and dedicated place where everyone could even comment it beforehand and the host to add it to the agenda ;)

merging released branches

Don't understand sorry

Some if using github can facilitate this then sure, but so can email.

Note that I'm in no way trying or even suggesting to drop e-mail collaboration. But I'd be a supporter of a more strictly enforced policy for threads object respect and message formatting...

[c-morley]

Milestone -fair enough milestones can be used both way and both are useful. In my opinion, setting dates for say releases is really the most import thing - so that people of different time zones and free time can sync. But yes milestones with no dates do show a direction and that would be good too.

Debian schedule - I have no idea of Debian criteria/goals (probably a good thing to write)- in principal it seems like a good goal, maybe will help with deadline setting. Hopeful helps with getting users and devs interested. We need to get our house in order I think or it may become too difficult to do everything needed, with the people we have. IMHO we should create the 2.9 candidate right now - there is work that can be done, it sends a signal, and allows master to be a little unstable, while still having a useable (for the brave) branch with the new features. I send an email about this and got really no response.

merging branches up - this is the common thing to do on git projects apparently. It is a silly thing to do on our project AFAICT. I've asked why we do it and never get a good answer. always 'cause that what everyone does' or some one explains the process of merging, which of course I already know.

• conflicts, set a high bar for devs to merge - what do I know about translations for instance? So either I don't merge and let someone else suffer or I guess what should be done, and people guessing causes problems. I have has to fix bugs multiple times cause the merge was wrong. Cherry-picks or preparing separate patches for each branch is easy and if there is conflict (with cherry-picking) the code is mine so I know how to fix it. This just came up with Andy wanting to backport work and the translators are worried about wasted work fixing conflicts. all goes away if you don't merge. As I said I have never got a good answer why up merging is worth the trouble.

I was present in the zoom meeting briefly - the audio for me was so bad it was useless. I tried to speak up a couple times and seemed to fail. I could only hear about half of what was said. Face to face meetings are fine for some things that need answers quickly, but with an international group they are difficult to include everyone and without summary everyone else misses out (IRC is similar but at least it can by read latter) Also where is the link posted so someone could find it?

Email is nice because of the low bar to entry, you can respond at anytime and it can be threaded to follow the conversation - but it's slow for sure. Everybody has their favorite form I suppose.

Thanks for the interaction and letting me explain my thoughts, I'll try not to turn into a 'negator' :)

[smoe]

You guys are talking way ahead of what we need to start with. And that's ok, forward thinking is good. But: We still haven't picked an official date for 2.9 (aside from 'in weeks' and 'this year') We still don't even have a 2.9 branch to actually work on. We seem to think it's a good idea to stabilize our development branch for release - in the development branch. We don't even use the mail list effectively, using github is a higher bar.

@c-morley - please get in touch per PM with @hansu who is the master of ceremony for our next video conference shape the agenda of that meeting to your liking. And maybe you should be the one orchestrating the meeting that then follows.

[hansu]

@c-morley - please get in touch per PM with @hansu who is the master of ceremony for our next video conference shape the agenda of that meeting to your liking. And maybe you should be the one orchestrating the meeting that then follows.

You can just edit https://docs.google.com/document/d/1aWMxBY8IbCYXFLFvjgqUXZ09inZp5u0r-pZcjeb2bWk/edit. If you don't have access, reach out for @smoe.

[c-morley]

I really don't like the video meetings much. I don't understand why we need a video meeting to discuss.

[petterreinholdtsen]

[c-morley]

I don't understand why we need a video meeting to discuss.

The video meetings help build communicty and bring (back?) the fun in the project for those that almost have lost it. Both of these factors need higher bandwidth communication than what email, IRC and web forums can provide. I am sure there are other ways to get the same effect, but we have to play with the cards we currently have.

-- Happy hacking Petter Reinholdtsen

[c-morley]

I don't see how 2 hours every month is more bandwidth then a month of emails/github conversation. I'm not saying that there is no room for video meetings - I am saying we could have things already figured out or at least targeted to few decisions by the time the meeting comes.

We are an international group, finding a time that fits for everyone and to have enough time to fully discuss things is near impossible.

I don't really understand why people don't want to discuss things. To make the project/community better we need to interact and challenge each other. Even if we are wrong sometimes. The more we interact the better - waiting so we can see each other on a screen is a little less important.

[hansu]

I don't really understand why people don't want to discuss things.

I don't think people don't want to discuss things. But in the video meeting you would always get an answer, sometimes that is not the case for questions stated in issues or in mails via the mailing list.

[c-morley]

Ya that's the part I don't understand. If you care about releasing 2.9 for instance why would you not put an opinion in an email. Or we should close the mailist.

Anyways thanks for trying to help me understand.

[phillc54]

I have little interest in video meetings (even less at 4am), I would prefer email discussionsCheers, Phill. 🙂 -------- Original message --------From: c-morley @.> Date: 29/8/22 4:15 am (GMT+10:00) To: LinuxCNC/linuxcnc @.> Cc: Subscribed @.***> Subject: Re: [LinuxCNC/linuxcnc] Extend GitHub features usage (ie Labels, Projects, Milestones, Discussions, Wiki) (Issue #1960) Ya that's the part I don't understand. If you care about releasing 2.9 for instance why would you not put an opinion in an email. Or we should close the mailist. Anyways thanks for trying to help me understand.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[snowgoer540]

Seeing as this issue was created 8 days ago and I am just now seeing it, I don't find Git to be an effective means of communication either.

While I consider myself to be very interested and active in this project, I also have to say that I have little interest in attending video meetings. Not to mention the fact that the last few have happened while I am at my day job. I also would prefer email conversations. I may not always participate, but I do always read them, and it helps me stay in the know.

I worry about having an additional new place to check things, and keep up with what is going on. Between the forum, git, and email, surely one of those can work for everyone.

I also worry about decisions being made solely because those who attended the video meetings agreed, without the input of those who cannot attend. Or perhaps a better way of saying this is I worry about someone's opinion being devalued because they could not attend the video meeting.