|
Am 10.01.2013 11:25, schrieb Jan-Peter
Voigt:
Great!
I would like to join in and I am going to host my
lib/framework on github too with the option and goal of
integration with openLilyLib and/or later lilypond.
That's great too!
This morning I created a github account,
What's your user name? I'd like to add you.
The standard way to collaborate on a Github project is to
- fork a repo (i.e. create a personal copy of it)
- make modifications to your fork
- send a pull request (ask the maintainer to merge your changes
into the original repo)
While this is a perfect way to start participation in a project
whose maintainer doesn't know you, it's more straightforward to be
an explicit collaborator with push access to the repository.
And I think we can be rather generous with that.
so I am not familiar with its services (beside the usage of
GIT).
... which is _far_ more than 50% of the problem (i.e. won't face you
with any serious problems.)
What are you missing regarding the issue tracker?
Sorry if I can't put my fingers on it very concisely (I'm still sort
of a beginner in these areas), but as a general remark I find it
somewhat too simplistic.
It's a tool that you can start to use right away (that seems to be
Github's objective in general), but the downside is that it isn't
very refined.
A few issues compared to LilyPond's issue tracker on Google Code:
- Filtering issues isn't very good
- You can't give priorities to issues
- No mechanism to verify issues
- No option to merge issues
- (don't find more right now, but there surely are)
Someone else pointed out that it is a real problem that one (i.e.
anybody) can edit issues and comments. You can change a message
afterwards without leaving a trace from that.
The only real 'advantage' of Githubs tracker is that it is
integrated with Git. So you can reference or close issues directly
from commit messages. This is nice, especially because you'll get
a message in the issue saying 'this issue was closed by commit
<link>asdpfj02395</link>.
But I don't think that's really worth sticking to it.
Best
Urs
Best,
Jan-Peter
Am 10.01.2013 um 10:43 schrieb Urs Liska:
Am 10.01.2013 09:03, schrieb
Janek Warchoł:
(i cannot resist my lilypond addiction...)
On Thu, Jan 10, 2013 at 12:09 AM, Urs Liska <address@hidden> wrote:
But I probably won't touch [online tutorial] until I reformat it as a PDF version. There
had been some valuable comments on this list right after the first 'release'
of the tutorial - which still haven't been incorporated :-(
That's why git and github rock - someone could write the changes and
you'd just have to accept the pull request.
I strongly recommend using text input for such project (which is
really great BTW!), because text input make version control effective.
I understand that LaTeX might be scary for beginners. Maybe simply
use formatted plain text? (something like markdown, for example).
If nobody comes up with a better suggestion or serious
objections - or if nobody else just offers to maintain the
project and wants to do it differently - I will do the
following:
- Host openLilyLib in the existing Github repository
(I didn't intend to start with this already, so it
will be kind of a stub for some time)
- Maintain the library's documentation and the
tutorials (starting with Antonio's proposed text on
orchestral scores and hopefully with a conversion of
my existing tutorial) as a set of LaTeX documents.
- I think there is no real alternative to this because
- LaTeX documents can be easily versioned with Git
- We are talking about LilyPond, so we wouldn't want
to expose anything less (e.g. a collection of
inconsistently looking PDFs created from various
applications)
- These documents can then be rendered as individual
files or as a compiled 'book'.
- Contributors are encouraged to provide LaTeX sources
too, but
- markdown or even plain text files would work too
- if we are talking about the contribution of
complete tutorials, it is also appropriate to aid in
converting from, say, reasonably structured
OpenOffice or Word documents
- As a last resort we can even incorporate PDF
documents (e.g. in case someone stumbles over an
existing PDF where the sources have been lost ...)
- We have to decide upon platforms for a 'public
frontend' to the project, a mailing list and
optionally an issue tracker (although Github offers
one)
Current suggestions point to use Google services for
these parts.
Best
Urs
best,
Janek
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
|