FreeCAD / FreeCAD-Enhancement-Proposals

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

add FEP00: A Template for FEP's #1

Closed looooo closed 4 years ago

looooo commented 4 years ago

This is a template for FreeCAD-enhancement-proposals. Feel free to review or criticize.

yorikvanhavre commented 4 years ago

In any case it's a good initiative to launch the discussion.

looooo commented 4 years ago

This looks good! But I wonder, most of the time someone will fill in such a request, it might very well stay there lost in oblivion... Not to mention the fact that we might migrate out of github at some point if it becomes evil... Wouldn't it be better to redirect to our tracker? Or maybe set up a kind of "what will happen with your request" procedure?

yes I thought about this too. But I guess in the end we have some documents which need to be transferred to another repo. Using the github-infrastructure is not really important for the target of the repo. It's not the goal to create any restrictions/rules. It's more about creating some proposals for the future of freecad. I guess we should simply try it : )

ref: https://forum.freecadweb.org/viewtopic.php?f=8&t=40728

vocx-fc commented 4 years ago

You should add @WandererFan to the list of reviewers.

looooo commented 4 years ago

I would like to add all of the people in the github freecad-group,but there s a limit of 15 reviewer...

looooo commented 4 years ago

Only members of the freecad-github team can review proposals. I tried to create another group, but only members of the freecad-github-team can be members of a newly created team... This is not good as there are for sure many more people which should have the possibility to review proposals.

luzpaz commented 4 years ago

Looks great. I would recommend we take advantage of the github markdown checkboxes. Example:

WandererFan commented 4 years ago

Is this going to replace feature requests on mantis, leaving mantis only for bugs? It's a good template for requests. Feels a little "corporate" for the FC community. Maybe it is time.

looooo commented 4 years ago

Is this going to replace feature requests on mantis, leaving mantis only for bugs? It's a good template for requests. Feels a little "corporate" for the FC community. Maybe it is time.

No, I didn't want it to replace feature requests on mantis. Things I would like to adress with this repo are:

But if the community thinks we don't need another tool, we have to accept this. This is why this can only be merged if ~3~ 6 people give the ok.

furti commented 4 years ago

I have a question about the table at the beginning of the template.

It is written in HTML. But Markdown supports tables also. https://www.markdownguide.org/extended-syntax/ Don't know if all renderers support this. But wouldn't it be better to use the markdown table syntax?

looooo commented 4 years ago

@kkremitzki Thanks for this example. Definetly something I would like to adress too. Hardoding the Version in the Version.h file of the release branches would be my suggestion to solve this. But creating a proposal would definetly help to see what different maintainers think about it.

@furti Restricting the proposals to markdown only makes sense to me (keeping the result independent from github). But we might miss some features like checkboxes @luzpaz ?

furti commented 4 years ago

@looooo The thing ist, tables, tasks list and stuff are not in the basic Markdown specification. https://www.markdownguide.org/basic-syntax Instead companies extended the syntax over time to support more usecases directly. I checked the GitLab Markdown syntax. And at least tables and task lists are the same for GitLab as for Github. https://docs.gitlab.com/ee/user/markdown.html#tables https://docs.gitlab.com/ee/user/markdown.html#task-lists

I also used mutliple markdown parsers over time. And they all supported tables the same way.

I think it is save to also use extended markdown syntax where possible. The advantage of Markdown is, that even when the renderer does not support the syntax, it is still easily readable.

A task list would be displayed like this when not supported by the renderer

Some text

- [ ] Task 1
- [x] Task 2
...

In my opinion the intention is pretty clear, even when there are no checkboxes displayed. The same for tables. Even when not rendered as HTML Table, a Markdown Table is much easier to read in text form as a HTML Table

Markdown

| Heading        | Heading |
|----------------|---------|
| Some Text      | 123     |

HTML

<table>
<thead>
<tr>
<th>Heading</th>
</tr>
</thead>
<tbody>
<tr><td>Some Text</td></tr>
</tbody>
</table>
looooo commented 4 years ago

We still need 3 reviewers to get this merged... Anyone?

vocx-fc commented 4 years ago

I just realized that you have BPLRFE as one of the reviewers. I think this is Roland Frank's account. You should take him out of the list.

luzpaz commented 4 years ago

@wmayer / @yorikvanhavre what say you?

looooo commented 4 years ago

@WandererFan

I'm still a little fuzzy on just when it would be used. Presumably PDN or the BigMerge would have been candidates? TopoNaming? Py2 -> Py3?

Yes, exactly these would have been candidates. Whenever a decision has an impact on multiple developers/users and making the decision is not straight forward. But also defining policies / best practices when multiple ways are possible. I guess these are the main targets, but best to have a look at the examples we listed in the issue section: https://github.com/FreeCAD/FreeCAD-Enhancement-Proposals/issues/2

looooo commented 4 years ago

Nice. There were some problems with the accepted reviewers (somehow all reviewers need to have write access) but it should work now. I guess it's not possible to restrict the author of a proposal to not merge the PR, but it would be nice if we can agree on this rule. I know these restrictions are a bit oversized for a template, but for more difficult proposals it makes sense to do so. So please press the merge button @kkremitzki @yorikvanhavre @luzpaz . I hope you should be able to do so.