[meta] Collaborator discussion

[formatc1702]

[formatc1702]

I've created a new milestone to show which features I'd like to have included in the next release, i.e. pushing to master as well as uploading the new package to PyPI.

If anybody wants to suggest more issues to include, please let me know. However, my aim is to release v0.2 relatively soon, which is why I've deliberately left out a lot of existing requests.

[formatc1702]

Uptate on the v0.2 milestone: I've assigned people for most open issues/PRs, hoping to be able to assign #114 soon too. If anybody wants to take on #60, please comment there and I will asign you.

Additionally, I've made a milestone for v0.3, which currently only serves to denote issues/PR drafts that I know I want to pursue as soon as v0.2 is out, but not before.

[kvid]

Have you considered #116 and #121 for the v0.2 milestone?

[formatc1702]

Added both! Thanks.

[kvid]

I just made a suggestion in the closed issue https://github.com/formatc1702/WireViz/issues/122#issuecomment-667545193. Do you think it should be reopened?

[formatc1702]

Feel free to do so!

[kvid]

Feel free to do so!

I don't know how. Maybe I'm not authorized to do it.

[formatc1702]

Not sure.. did it myself now :)

Perhaps only repo owners (and maybe the original commenter) have the "reopen issue" button...

[kvid]

Not sure.. did it myself now :)

Thank's

Perhaps only repo owners (and maybe the original commenter) have the "reopen issue" button...

You are right. I certainly did not see that button here, but I can see it in one of the closed issues I opened myself.

[formatc1702]

Just a quick FYI especially for @kvid, I'll be taking a couple of days off coding to breathe a bit, and I promise I shall be back to read through all the comments, commits and other contributions as usual. It will help me get back my focus and ensure v0.2 gets released with no major issues :)

[formatc1702]

My goal is to get v0.2 released by the end of the week.

• #27 / #153 is almost ready for merging
• #107 / #111 needs to be updated to reflect the above PR and is then ready, too.
• #60 / #98 / #123 have been postponed to v0.3 due to inactivity. I'm assuming this is due to the holiday period and I hope the authors make a comeback at some point :) Otherwise, I'm sure us other contributors will find a way to work on this while keeping the authorship intact.

"Perfect is the enemy of the good", so let's get this release out soon and hopefully receive feedback on the new features. I suggest that after the release, we can decide on prioritizing the upcoming issues to get another cool set of features for v0.3!

Thanks everybody who's contributed so far, with major kudos to @kvid for submitting good PRs and doing some thorough code review!

[formatc1702]

Unforeseen circumstances prevented me from working on WireViz this week, so the v0.2 release will have to wait another 2-3 weeks until after my holidays 😐 oh well...

[formatc1702]

Here's a quick update for everyone, especially for @kvid, @Tyler-Ward, @martonmiklos, @zombielinux [and others?] who have submitted contributions while I was gone. Thanks a lot for your continued support, and interest in this project!

I hope to resume reviewing/merging/coding in the upcoming weeks, so don't worry, this project is not forgotten!

Holidays, personal and work related issues have kept me busy and delayed things quite a bit... I will get back to every single issue and PR and integrate them into the project one by one as I find time to keep working on WireViz. I need a few more days to be able to continue, but rest assured, I am looking forward to integrate new features and get new releases out the door! Cheers!

[kvid]

When the PRs are ready and unless rejected by @formatc1702 , I suggest he merge them into dev in this order: #115, #164, #163, #153, and #111, but please give the PR authors a couple of days for rebasing on top of the new dev and resolving conflicts before each merge.

[formatc1702]

Thanks for the suggestion. I haven't looked at the contributions in detail; just one question:

Why not prioritize #153 and #111, which were planned for v0.2 already, get that one released, and then continue with the other PRs you mention? I'm worried that the v0.2 release will be further delayed if we try to include every new addition, and it might be better to make a clean cut between what goes into v0.2, and what will go into v0.3 and beyond.

If there's a technical reason that would prevent this, please let me know. Thanks!

[kvid]

Thanks for the suggestion. I haven't looked at the contributions in detail; just one question:

Why not prioritize #153 and #111, which were planned for v0.2 already, get that one released, and then continue with the other PRs you mention? I'm worried that the v0.2 release will be further delayed if we try to include every new addition, and it might be better to make a clean cut between what goes into v0.2, and what will go into v0.3 and beyond.

I see your point.

If there's a technical reason that would prevent this, please let me know. Thanks!

• There are no critical reasons that I know about. My line of thought was this: As many more PRs are ready or close to ready now compared to before your vacation, I thought perhaps you considered moving more of them into v0.2. #111 already describes ignore_in_bom and @Tyler-Ward suggested you cold move that part from his PR #115 into v0.2 - which is not a bad idea, but then during the last few days, the whole #115 has moved very close to ready, and I thought you would be tempted to move the whole #115 into v0.2.
• Given my assumptions, I suggested #115 first, since that one include a major refactoring of BOM generation that will benefit other PRs.
• However, as my assumptions that you maybe wanted to move new PRs into v0.2 was wrong, then #153 and #111 should be merged in first, and maybe @Tyler-Ward need more time than I think to get #115 ready (mostly because of my change suggestions), but after it gets ready, I hope you consider #115 soon rather than later. 😃
• #163 is kind of coupled with a #111 suggestion, but it should be possible to accept my https://github.com/formatc1702/WireViz/pull/111#discussion_r487467403 even before #163 is merged in.
• #164 is quite small, but potentially very useful for many users.

[formatc1702]

Thanks for the detailed answer.

• I will stick to finishing v0.2 with #153 and #111 first, to avoid "feature creep".
• I will then follow your other suggestions, and I see no reason not to release v0.3 soon afterwards... Since you've had a good eye on the project recently, I'm sure you can help pick out the PRs that are close to completion, and any burning issues that should be resolved and included in v0.3 as well.

There's tons of new stuff in v0.2 already, compared to the current master branch, so it's nice to keep some good stuff for the following release ;)

[stevegt]

@formatc1702 Let us know how we can help. I'm extremely impressed by how motivated and active the contributors to this project have been in its short life, and I'd like to do what I can to ensure its continuity. I'm already pretty sure the WireViz yaml schema could become a defacto industry standard, though that does raise the thorny issue of governance -- maybe some sort of RFC or PEP-like approach might work. I'm also thinking of suggesting you get on the waiting list for the github Sponsors program if you haven't already.

[formatc1702]

@formatc1702 Let us know how we can help. I'm extremely impressed by how motivated and active the contributors to this project have been in its short life, and I'd like to do what I can to ensure its continuity. I'm already pretty sure the WireViz yaml schema could become a defacto industry standard, though that does raise the thorny issue of governance -- maybe some sort of RFC or PEP-like approach might work. I'm also thinking of suggesting you get on the waiting list for the github Sponsors program if you haven't already.

Thanks @stevegt for the kind words! It has been amazing to see the project grow, and indeed, collaboration with all the contributors has been great!

I'll lookinto the GitHub Sponsors thing; however, I'm unsure whether monetizing the project in this way might negatively impact users' expectations, and contributors' attitudes, since a lot of WireViz is built on their work, not only mine.

[formatc1702]

Let us know how we can help.

Since my time for working on the project has been a bit limited lately, the following things have helped immensely:

• Contributors submitting high quality PRs, possibly rebasing onto dev if necessary, so all I need to do is nitpick a bit and click Merge ;)
• Contributors collaborating without my intervention and checking each others work (e.g. in #115), leading to the aforementioned quality
• @kvid keeping an overview of the various issues, how they interact, and suggesting an order in which to include them; as well as meticulously checking for uncaught mistakes and ensuring completeness of documentation, etc.

This is all highly appreciated, and I hope we can keep the momentum of the project going :)

[formatc1702]

Posting it here as well for completeness sake: v0.2 has been released, thank you everybody for your valuable contributions!

Over 100 forks and >2000 stars on the project really tell me we're working on something worthwhile here!

[formatc1702]

Short summary of the current situation:

• #192 seems to be working, will re-review it soon and merge
• I am currently working on #186 and hope to have a version that is ready for review soon-ish
• #181 has been updated to reflect the recently merged PRs
• I could use some help with the following:
  • Getting #171 ready for merge (high priority, has been waiting for a while)
  • Getting #168 ready for merge
  • ~~#189 might spawn a new PR for embedding images in the SVG/HTML output~~ #189 now includes a WIP of SVG image embedding
    • ~~I could tackle that after finishing the above PRs, but I will also accept contributions if anybody feels up for the task~~

As you can see, I'd like to reduce the number of open PRs first. Afterwards, I'll try and prioritize some issues that deserve attention :-)

[kvid]

Short summary of the current situation:

• #192 seems to be working, will re-review it soon and merge

• I am currently working on #186 and hope to have a version that is ready for review soon-ish

• #181 has been updated to reflect the recently merged PRs

• I could use some help with the following:

  • Getting #171 ready for merge (high priority, has been waiting for a while)

I have applied the commits from #171 + bugfix onto the current #192 commits and are ready to rebase it on top of dev and create a PR after #192 is merged in.

• Getting #168 ready for merge

I have done some work on this as well, but need more time because I'm not able to contribute every day.

[formatc1702]

Thanks. #192 is now merged; looking forward to merging your upcoming PR and closing all the related partial PRs.

[amotl]

Hi @formatc1702, @kvid and @stevegt,

within #211, we just reported about our efforts on bringing WireViz to the Web. It has actually just been a (re)packaging operation of code already conceived within the community (thanks, @elbosso!). However, we hope you will appreciate having this available as a standalone package and we are looking forward to any contributions and comments.

Happy hacking and with kind regards, Andreas.

[amotl]

Hi @formatc1702 and @kvid,

we just recognized that many improvements have been made on behalf of [1] and [2] (#197) already. Those look like valuable improvements to WireViz.

Just let me know when you are ready and I will update wireviz-web accordingly.

With kind regards, Andreas.

[1] https://github.com/formatc1702/WireViz/tree/dev [2] https://github.com/kvid/WireViz/tree/simplify-BOM-code

[formatc1702]

Sorry for the lack of activity.

Here's the current state of things:

• As you can see, I have not had the time / mental capacity to take care of the project as much as I had hoped; however:
• I have been using WireViz extensively at work, using a "hacked together" branch that implements #239, #186 & #214 and I am very pleased with the results. It's nice to be able to use WireViz in a production environment.
• I hope to be able to merge these PRs into dev soon, to reduce the number of open PRs.
• Some of the other simpler PRs should also be included before/after (#197, #219, #229)

I cannot promise a time frame for this, but I am hopeful that I can start the project moving again in the foreseeable future ;-)

Thanks everyone for your contributions.

[formatc1702]

@kvid if you could let me know what order the mentioned PRs should be merged, and whether you need to do anything on them, that would help me to integrate them in the most painless way possible :) Thanks.

[kvid]

As #197 and #229 are already merged, #214 and #219 can follow in that order. I have rebased them both on top of the current dev. Please review them (anyone?) to increase the quality before merging. ~~It should be possible to merge #229 both before or after them, but I have not checked for conflicts.~~ I experience a lot of conflicts with import statements while rebasing. I think we should consider splitting imports into several lines (one identifier per line) and sort them alphabetically per import statement to reduce conflicts. Maybe there is a PEP describing this?

[kvid]

I think this project follows PEP8 import guidelines more or less, but I think we should also consider sorting imports according to some common rules to reduce merge conflicts. Maybe a tool like isort can be used to automate the task? Some projects also combine isort with black to force a fully unified code formatting on all Python files. Please tell about your own experiences with formatting rules and tools like this.