About issues and PRs.

[Akhilesh-max]

Hey, @birm, I’m planning to make some improvements. Is it necessary to open a corresponding issue for every Pull Request, or can I directly open a PR?

[Akhilesh-max]

@birm, Also, I have noticed that you're merging Pull Requests into the develop branch. Should I be pulling changes from that branch only?

I ask because even though master is our default branch in caMicroscope, it seems that PRs are being accepted into a separate develop branch. I've been pulling from the master branch so far. Is that the correct approach?

[gbengaoluwadahunsi]

oooh nice, I have observed the same, let's wait for @birm response.

[NgweBecky]

O really, little did I notice. Thanks for pinging this.

[birm]

For repositories which have a develop branch, we like to merge there. It's like a second layer of testing; we test when we merge a PR into develop, and we occasionally do a "release" where we merge develop in to the main branch.

[Akhilesh-max]

@birm I was contemplating, as we are directing our commits to the develop branch instead of master, and not synchronizing the master with the PRs, wouldn’t there be potential issues if a PRs were to conflict?

[birm]

There sometimes are conflicts; not too often though in practice, it seems. Usually the PRs seem to touch different parts of the codebase.

[Akhilesh-max]

@brim I’ve also proposed an issue to migrate caMicroscope to a some modern-day frontend framework. If this aligns with your vision, I could adopt this as my GSoC project and commence work on it immediately. Please share your thoughts on this.

[Akhilesh-max]

@birm I have a rough proposal for the project title as Accessibility Testing and Improvement. May you please take a look at it? If so, how should I share that with you?

[birm]

You don't need to make an issue before a PR, but you should make sure that between the PR description and the issue (if you decide to open/reference one) it's clear what the issue/problem is and what the fix is.