search

FreeCAD / FreeCAD-Enhancement-Proposals

FreeCAD-Enhancement-Proposals (FEP's)
GNU Lesser General Public License v2.1
9 stars 2 forks source link

Workflow #3

Closed sgrogan closed 4 years ago

sgrogan commented 4 years ago

Now that the template is merged I'd like to discuss the workflow. I envision it working something like this;

Fork this repo Clone the repo locally Create a local branch Copy and rename the template Fill in the template (maybe partially) Commit and push to forked repo Open an issue here with a link to the forked repo and a link to mantis if applicable Refine the proposal through discussions in the issue, pushing commits to the forked repo or accepting pull requests to the fork Make a pull request against master here Further refine the pull request Merge after review (here the pull requester should not be the one to merge) Implement the proposal Close the issue here and mantis if applicable

After discussion maybe I can make a readme.md for the master branch. The intent is not to make this too corporate, but maybe for these type of intrusive change we need some structure.

Please don't hold back on criticism.

furti commented 4 years ago

I think to have a well known workflow for this is a pretty good idea. I also like your proposal. But I have a few questions:

  1. Why is the link to mantis in the issue. Wouldn't it be better to have the mantis link directly in the Proposal?
  2. The workflow stops after closing the issue. What happens with the Proposal afterwards? Should there be an "Closed Proposals" or "Archive" Folder in the repository where closed proposals are moved to? Otherwise we have a potentially large list of proposals where no one knows what is still open and what is already solved.
  3. Do we really need an Issue for a FEP? Or is it enough to create a pull request, where the discussion about the FEP happens. Otherwise part of the discussion happens in the issue, other parts in the pull request and it is hard to follow.
sgrogan commented 4 years ago
  1. Agreed. We could add it to the template, either in the Table at the beginning or put the link in the motivation section. I prefer the former.
  2. This can be handled by the status section of the template. I will add this to the next iteration of the workflow.
  3. Agreed again. I was thinking of draft type of proposals, but draft is an option in the status section so it is better to keep everything in the pull request.
looooo commented 4 years ago

@sgrogan

After discussion maybe I can make a readme.md for the master branch.

A workflow description would be nice to have. I had a look at conda-forge-enhancement-proposals and they seem to have a proposal for this: CFEP-01 But I think your suggestion (using the README.md) is a better solution.

@sgrogan

Why is the link to mantis in the issue. Wouldn't it be better to have the mantis link directly in the Proposal?

@furti

Agreed. We could add it to the template, either in the Table at the beginning or put the link in the motivation section. I prefer the former.

Agreed I should have added an issue-section for the template. I will add this in the next couple of days. If you have any other ideas for the template please mention this in the upcoming PR. The reviewing is quite time-intensive and doesn't make much sense for the more administrative work like template and workflow description. But I would like to keep these rules to make sure this is really community-driven.

@furti

Do we really need an Issue for a FEP? Or is it enough to create a pull request, where the discussion about the FEP happens. Otherwise part of the discussion happens in the issue, other parts in the pull request and it is hard to follow.

I think if you have a clear vision on how the proposal should look and that the proposal makes sense also to others, directly creating a PR makes sense (further discussion can take place in the PR). If you don't know if the proposal is necessary best to create a forum topic (discussion). I guess the issue-section in this repo should be used for issues with proposals and administrative issues. The forum should be the first place for discussions. Once a possible solution is found adding a proposal via PR is the next step. Further reviewing/discussion/refinement can happen in the PR.

Vanuan commented 4 years ago

I think this is too formal. Let's start with something simpler, like GitHub wiki pages and see how many proposals we could get. And especially, what kinds of proposals are there.

Vanuan commented 4 years ago

Let's try the wiki workflow and see how it goes;

Create a wiki page, write a proposal, discuss on the forum, make corrections, finalise, implement, archive or maintain

looooo commented 4 years ago

As said we should still use the PR's to come to conclusions. Also, voting is necessary to make the FEP's worth anything. So don't bypass this step. But as already said, I agree on using the wiki as a kind of drafting tool. Once we are ready to transform this into something more official create a PR from the wiki file.