Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation #89

Open
CsatiZoltan opened this issue Feb 21, 2020 · 2 comments
Open

Documentation #89

CsatiZoltan opened this issue Feb 21, 2020 · 2 comments

Comments

@CsatiZoltan
Copy link
Contributor

Some information can be found about ImagePy but they are scattered around the main repository, the demo plugin and image.sc. I propose creating a repo just for the documentation (could be hosted on https://github.com/Image-Py/imagepy-doc). I also recommend revising the spelling.

We could also document the input and output parameters of the most important methods, the user may often come across. Combined with a Doxygen documentation (see #63), new users could use ImagePy more efficiently.

@yxdragon
Copy link
Member

document is the a problem for a long time. I did not have much time (you known, sometimes document need more energy than coding), and my english is not very good.

I think there are 3 types of document. sorted by importance:

  1. user menual
    for ImagePy is a bridge from developer to user. In this point, imagepy.doc folder, we can write some markdown file there, with the same structure and name with the plugins folder. Then it would be linked by the help button on parameter dialog. (if no parameter, or a tool, it is linked by right click), but I just put a demo in it now. (In fact I had tried to write a book, just like many imagej's book, and I has wroten many, but give up temporary)

  2. the developer document
    I think the best way is writting demos. such as the demo plugin. may be some more demos is needed such as how to use ips.data. I think a good framework should be: a science programer can writting plugin easily, and need not know the framework well.

  3. framework api document
    the doxygen document is a framework api, I am reconstructing ImagePy and split the ui as sciwx. When I comleted, we can rebuilt a doxygen.

In the end, may I invite you to imagepy's organization?

@CsatiZoltan
Copy link
Contributor Author

Your classification makes sense. I propose the following:

  1. User manual
    You create the hierarchical document structure. Then we can start writing the documentation.
  2. Developer documentation
    You know ImagePy the best, so you could write the documentation (as your time allows) and I can revise it. I am not a native English speaker but I think I could catch some spelling mistakes and also notice if something is not clear. During the revision, I can learn both about Python and the working of ImagePy.
  3. API documentation
    Currently, I have no idea concerning this one.

may I invite you to imagepy's organization?

Yes, please. That would allow me to manage labels, milestones, etc. Since I am a beginner Python programmer, I will work on my own fork and contribute in form of pull requests. That way I cannot mess up the main ImagePy repository and you can edit my changes to conform to your needs.

This issue could be pinned on the main page to catch attention. Also, writing the documentation is a larger task, needing some planning. Hence, a project could be set up for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants