Partkeepr: Meta: Too many open issues

so basically we create a de-facto "backlog"...
@Drachenkaetzchen are you open to adding a couple of us to the project so we can bring some order to the issues?

so basically we create a de-facto "backlog"...

Sort of. But, yes, this is the basic idea.

@Drachenkaetzchen are you open to adding a couple of us to the project so we can bring some order to the issues?

I would be willing to help here, if desired.

Hey guys, this is a very good idea and was discussed by us on IRC as well.

I recently got access to the github and I will have a look at adding some more people to help out with the organizational side to manage the issues and appreciate your offer to help with this.
(if due to time-constraints I forget don't be shy to give me a poke about it)

Ok @christianlupus I've added you as a Triage member to this repository.
@baradhili are you interested as well to help out with this?

Here is described the capabilities for this: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Eventually of course we'll add some more people with code access as well. For now lets try and get some focus on organizing the issues.

@dromer yes please

@dromer Thanks for the add.

A first suggestion is to add a label needs-triage and setting up a rule to put every new issue and PR into this label.
Reason: The reporter sees that a triage is needed/going to be done. Further we can sort (later) for such issues. Maybe we should consider putting every issue under this label in order to see what is done already and what needs attention.

And additional: I suggest the following labels as well:

• meta: Used for issues not related to the code itself but the repo, the wiki, the programming standards and the like
• help-requested: Used to indicate that an issue is seeking for help during setup, usage, etc. This might be better pushed to a forum than kept as an issue here on github.

Sounds good.. though I'd suggest we don't plonk everything under needs-triage because we'll simply end up where we are now :).. I'd also suggest backlog , next-release and roadmap once we get things under review

As I started to categorize a few issues now, I found it difficult to put labels on them unless these are defined clearly (at least for a part of them).

@christianlupus how do you want to coordinate the triage? I'm in UTC+8

@christianlupus Looks like we might need another tag "move-to-wiki"

@christianlupus how do you want to coordinate the triage? I'm in UTC+8

@baradhili I am in UTC+1 (Berlin).
I was giving a few issues some labels and a milestone when applicable. However it gets time for me to get to work now. So I will pause for now.

Do you have any good suggestions about the coordination? One person in the morning one person in the evening to avoid collisions? What is your preferred time to work on it?

As I do not know which city you are living in, I took one randomly from the named timezone: Here you can get a quick overview to manage the time shift. You might want to adopt to you city.

@christianlupus Looks like we might need another tag "move-to-wiki"

Yup, that seems to be the case.

@christianlupus I'm working through old issues with bug tags at the moment.. I think I can put an hour in around 8 or 9am my time...I use the english version of the same site - I'm in Perth - we probably want to flag issues that are complex with some kinda tag so the other can have a look and give an opinion..

@dromer if we give you a list of new tags can you add them?

Oh, is this something I need to do?

Let me know and I'll look at adding some more.

@christianlupus I'm working through old issues with bug tags at the moment.. I think I can put an hour in around 8 or 9am my time...I use the english version of the same site - I'm in Perth -

OK, this is completely up to you. Thank you for helping here. I am working on the unlabeled issues for now, so we are not colliding.

we probably want to flag issues that are complex with some kinda tag so the other can have a look and give an opinion..

Yes, I think this is a good idea. How about complex-triage?

Oh, is this something I need to do?

Let me know and I'll look at adding some more.

We can only attach labels and milestones to the issues. But we cannot add new labels to the list of valid ones. So, yes, we would ask you to add the relevant labels.

@baradhili So for not we have this list of new labels (please correct me):

• meta
• help-requested
• move-to-wiki
• complex-triage

About the timely labels (backlog, roadmap, next-release) I think this is better caught by milestones, don't you think? Also this must be coordinated with anyone providing code to the repo.

I will update this comment as soon as needs for new labels are popping up. OK with that? If yes, feel free to ask dromer about it.

@dromer
Could we have the following labels setup?

• meta
• help-requested
• move-to-wiki
• complex-triage
• security-issue

Thanks

@baradhili I tried to organize the labels in a MD file a bit. I added you as a collaborator so you can edit the file.

Are you ok with the definitions as far as I wrote them?

All good! documentation!

On Tue, 14 Jan 2020 at 19:36, Christian notifications@github.com wrote:

@baradhili https://github.com/baradhili I tried to organize the labels
in a MD file
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
bit. I added you as a collaborator so you can edit the file.

Are you ok with the definitions as far as I wrote them?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4JJYQ#issuecomment-574133474,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Bret Watson
Director
IT Interim Management Pty Ltd T/A TICM
Mob: +61 (0)41 33 03 840
Email:[email protected]
"The contents of this e-mail transmission are intended solely for the named
recipient(s), may be confidential, and may be privileged or otherwise
protected from disclosure in the public interest. The use, reproduction,
disclosure or distribution of the contents of this e-mail transmission by
any person other than the named recipient(s) is prohibited. If you are not
a named recipient please notify the sender immediately."

build system clearly has to do with the ci/cd (see my 2 PRs) so I would keep it.

I will add your list @baradhili and hopefully you guys can at least move forward.
For now I think it's ok to have 'too many' labels than to have 'too few'. We can always remove/ignore certain labels.

Any particular colors you want associated with them? :)

Ok too late, I went with the default colors for now :D

@dromer Could we have a milestone for 1.5.0?

@christianlupus I'm going to use 1 - Ready for things that appear/are claimed to be fixed, but need testing

@dromer in retrospect.. I realised I can handle things that look like they need to be done "Soon" with Must Have
@christianlupus finished Bug.. now working on old issues with no milestone

I remove the labels like Will be closed soon! and Feedback Needed as soon as an issue can be closes. Is this ok for our common workflow?

@dromer could I have one extra tag.. low-hanging ? I see issues from time to time that should be easy fixes

@christianlupus yes.. and I should go back through and check that I've done that

Apparently github provides some automated 'hooks' if you use the tag good first issue instead:

Label issues and pull requests for new contributors

Now, GitHub will help potential first-time contributors discover issues labeled with good first issue

So shall I call it that instead?
Issues with this tag will appear in some other overviews that are supposed to encourage people to get involved.

Like on https://github.com/partkeepr/PartKeepr/contribute

works for me! :)

@baradhili I worked my way through the untagged issues just now. To be honest, I will not proceed for today, this was enough. Nevertheless, I wanted to arrange with you the next steps. Looking forward for your reply.

@christianlupus yes.. I found I can sustain about 20/25 issues per day.. after that my brain is fried...
I will have a run at it this morning..

@dromer next steps we would probably have to start looking at prioritisation.. and most importantly.. assigning to devs.. do we have any devs?

@baradhili I just sent you an email to your ticm domain. Can you please check your account?

do we have any devs?
Er ... if we did we wouldn't have this backlog :)

I think you guys are moving a bit faster than the project currently 'allows', which is a good thing since organizing the backlog was clogging things up so hopefully prioritization will help put some focus for those willing to contribute. (finding them, or have them find us, is a different challenge of course)

ok guys.. we now have an issues list with all issues assigned to a milestone and quite a lot closed
I think our focus now is to get someone developing :) sadly I have NFI around ExtJS and Symfony so can't help...

options

1. we get a sponsor and use freelancers on guru.com or stackexchange
2. we try and find some ourselves
3. ?

Furthermore, you should ensure not to to kick somebody in the teeth by removing its hard work without contacting him. This happened to my printing function and since then I was only watching from the side line what is happening here. I also stuck with a piece of software which is useless in newer version, because there was no such function added again.

There should be a clear structure how to deal with such things and also with architectural decisions or what is a good practice to do something. The project itself is clear structured and also persons not being an php expert (but a programming expert in other languages) can implement things easily with some help to the used frameworks and structures.

@Boldie Hi Sven, apologies if your work was removed without notice.. things have changed a lot in the project in recent times and we are very keen to build the trust of the community - _especially the developers_

BTW - I'm assuming your printing function does bulk printing? what would be necessary to make it work again?

There should be a clear structure how to deal with such things and also with architectural decisions or what is a good practice to do something.

This is mostly correct but because the project was mostly managed in a one-person project. There was no need to define rules to interact with the community. As we start to share the weight of the project onto multiple persons it might be beneficial to define rules on how to proceed.

The project itself is clear structured and also persons not being an php expert (but a programming expert in other languages) can implement things easily with some help to the used frameworks and structures.

I assume you are a programmer yourself to be able to make such a statement with authority. I do not mean to offend anyone but in the meantime, I think it is harder to get your feet wet developing on the code.

I tried it but it was hard. The libraries are outdated like hell and documentation on these old codes are rare in the meantime. Further the project's documentation (e.g. #635) is not complete.
I am not bullying around here but I want to point out some critical problems of the current software. As the original developer is mostly unreachable at the time, we need people who know at least part of the code to get things back on track. I hope that "old contributors" are able to help here. There are a few bugs to be removed but the main problem is that the software is no longer maintained and maintainable regarding dependencies. We need to get the main issues solved, otherwise the project WILL fail.

So I ask you: Did you work on the code and do you have experience with the related dependencies?

BTW - I'm assuming your printing function does bulk printing? what would be necessary to make it work again?

@Boldie, I suggest that you open a new issue to track the missing functionality. At some point, this issue here will be archived. As a result, your request to get the printing functionality back working will be forgotten by most people.

BTW - I'm assuming your printing function does bulk printing? what would be necessary to make it work again?
It consists of 2 parts:

• The bulk printing of StorageLocations / Parts to a pdf
• Printing a single part (for labels)

The first one was highly integrated, but also adds some problematic dependencies. The second one maybe implemented again better using the REST API today. It is still tracked in one of these 200 open issues :)

I just had a look at the code: I have some problems on how this stuff is really working. The framework seems to use a kind of loose coupling which is hard to follow. Maybe an expert using this framework will say something different (most of the day, I have contact with C++ and sometimes python with django). I just remembered this also was hard to figure out how to add some stuff as I made my first implementation. The problem as I see is to lead this project from a more or less one-man-show to a community driven project. Unfortunately, I am the wrong person to help with the dependency problem, but I agree, this must be the first thing to solve in order to reduce the technical dept.

To ease development, I would suggest to setup a kind of environment one can easily start developing without doing work twice. In my company, we have setup a docker container with the stuff and also a script to run tests / add demo data , ... to make development start easy.

Is there a way to contact the community? I think most of the users are no aware we need some help here, otherwise the project will be more and more outdated and at some time non usable any more. Is it possible to put a statement to the homepage? Since there are most of the downloads, the people with proper knowledge are not aware of the situation and this repository here.

@Boldie Good idea! @dromer @Drachenkaetzchen does someone have access to the main web page?

@christianlupus Is there a list here or in the milestone view which work needs to be done next? I think one of the first things is to upgrade to Symhony4 #1083 ?

@Boldie yes, there has been work done to priorities issues. see this list:

https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Must+Have%22

Upgrading symfony, and other dependencies, is the biggest and most important one at the moment.
(althought I think the 'good first issue' tag is meant for newcomers, not for a 'needs done first' designation)

Is there a way to contact the community?
We are with a number of users in the #partkeepr irc channel on irc.freenode.net
There is also the google groups (a public and a private one), but I think the issue tracker + IRC are your best bet of talking to people about PartKeepr at the moment (in terms of activity).

Furthermore, you should ensure not to to kick somebody in the teeth by removing its hard work without contacting him. This happened to my printing function and since then I was only watching from the side line what is happening here. I also stuck with a piece of software which is useless in newer version, because there was no such function added again.

The reason I had to remove the functionality is documented here: https://github.com/partkeepr/PartKeepr/issues/622

If you feel you have been kicked in the teeth I'm sorry, but that's the way it was back then.

Also, I fucking spend most of my daily time writing this software. please fucking understand that if I have to remove code to make a newer version then for fucks sake so be it. you could have created another PR to make it compatible with the new version

yes, I'm fucking angry right now. I spent so many years writing the code for free, did the majority of the work, did lots of support work, tried to make a business and all I get for the hundreds if not thousands of hours of unpaid work is that.

if it wasnt my sense of responsibility i would have shut down the website and everything else 2 years ago.

i hardly have enough money these times to survive a month, having several illnesses which I'm unlikely to recover soon and I still try to keep this project somehow alive, even though I'm hardly being able to do so.

Also, I fucking spend most of my daily time writing this software. please fucking understand that if I have to remove code to make a newer version then for fucks sake so be it. you could have created another PR to make it compatible with the new version

yes, I'm fucking angry right now. I spent so many years writing the code for free, did the majority of the work, did lots of support work, tried to make a business and all I get for the hundreds if not thousands of hours of unpaid work is that.

if it wasnt my sense of responsibility i would have shut down the website and everything else 2 years ago.

i hardly have enough money these times to survive a month, having several illnesses which I'm unlikely to recover soon and I still try to keep this project somehow alive, even though I'm hardly being able to do so.

I know you are in a serious situation and this project including the community has a contribution to your situation. I also respect your work and I also thing this project (especially in comparison to others) has a well done structure, otherwise I would not try to brain what I can do to revitalize this project and how to get a development team ready for doing the necessary work.
I do not want to warm up the past now, It will not help us to go on further with Partkeepr.

From my daily job I know it is sometimes hard to deal with code from other persons especially if the person is not reachable (for future and if it is necessary, everyone can contact me by the email address from the git commits or using the domain and contact me using my homepage). Everybody has its own handwriting when writing coding. In my opinion its a kind of craftsmanship to write code. I also have a lot of experience with complexity and how hard it is to go through this, if one will do an upgrade of a library or a bunch of dependencies. I did this with a team for months in my paid work.
So now we have this challenge here again and we have to think of a way to do this with a community. It is much more challenging as in a paid environment where one will say: We will do it.

I had a look to the code and since I did something the last time it changed A LOT (someone invest a lot of work here!!:). So I had to dig into the code again and start working. But for this we need a close communication and roadmap what to do next. I think bringing back the printing functionality is very low priority in comparison to the other things and I or somebody else can do this later. For me it is more worthy not to loose my data with the next OS Upgrade in the future, because this will mean also a LOT of work to migrate to something else (I do not know what this can be), it tooks a long work in my spare time to fill the database.

Thanks @Boldie

@christianlupus @dromer I'm thinking we can close this one now that things are moving again...!

One more point to discuss: Due to the changes in #1091 all the new issues will have some tags attached. Do we want to have an indicator that no human review has been taken place here?

Apart from this I am OK with closing this issue now.

how is what we have done different to a human review? :)

@baradhili this is exactly what we did recently. I mean the following: since the named PR was accepted, any new issues will have either Bug, Feature Request or help-wanted preset as label depending on the type of issue selected.
That means that new issues (that have not passed manual triage that we did recently) will not present themselves as having no labels attached. So, there is no simple filter in GitHub to select those issues not yet humanly triaged.

So in short: do we want a need-triage or similar to indicate.

can we automatically add the needs-triage label under github's template system?

Yes, it is a matter of adding the label and changing one line in the template file. That should suffice.

I just opened #1097 regarding the issue templating system. If the needs-triage label is not wanted, I suggest removing the single commit.

closing this now