Hi everyone!
My name is Markus Schanta, I'm a 21 year old Computer Science student from Vienna, Austria and I would love to participate in the 2008 SoC and do some work on the project* modules.
The project* modules provide project management for Drupal sites. Generally projects are assumed to represent software that has source code, releases, and so on. The project* collection of modules (Project, Project issue tracking, and CVS integration) is the largest set of code running on drupal.org besides Drupal core.
I think there are several reasons why this module is important for Drupal. Fortunatley there's also good deal of work to be done here: see here.
It seems that there's really a big amount of "smaller" issues there. However, I'm not sure if any of theese is wide-ranging enough to consitute a SoC project.
Do you think it's desirable if a project consists of fixes to multiple problems, which need to be solved, rather than imlpementing "the one new big feature"?
If so, which issues would you recomend for a SoC project?
If not, can you think of any other project*-related work that can be done as a SoC project?
Looking forward to your answers,
Markus
UPDATE: After reviewing all the feedback I've been getting so far, I decided that I'm probably going to propose a Version Control related project. See this comment for more details.
UPDATE: I submitted my application through the GSoC web app two days ago. See this comment for the most recent version.
Comments
I can
But this is only if you are really willing to do tons of work.
Port it to 6.x.
Use Views, CCK, and the VCS API modules.
I already considered this before
I already considered this before. In case you want to know about this see the Project* roadmap for D6.
hm, great idea actually
I was hesitant to post a Project* project idea because I could not think of any huge blocker that would be able to be implemented separately from all the code that already exists. But there's indeed a large amount of work to be done, all of the mentioned points are of considerable effort, though only one of those probably don't justify a whole Summer of Code project,
+1 on a project that takes on several of the medium size issues.
oh, and by the way
I'm also a computer science student from Austria, and go to Vienna regularly. Plus I've worked on the revision control related stuff last Summer of Code, and have a good grasp on Project* too. If you need mentoring or further help, we could meet up sometime, and make sure you don't miss the next Drupal Austria user group meetup (will be announced in the respective group once the next date is fixed.)
Project* is really in need of contributors, you can actually make a large impact on Drupal and a good name for yourself by working on it. Extra credibility for taking on a few smaller issues before the Summer of Code actually starts :P
Help API
It's not a part of project* but the help API could use somebody who really wanted to make help work very well with project and having somebody with an interest in project* and working on a killer help system would be oh so much Drupal excellence...
--
Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch
--
Blog: Joshua Brauer dot com
+1 for work on Project.
"Do you think it's desirable if a project consists of fixes to multiple problems, which need to be solved, rather than imlpementing "the one new big feature"?"
+1 for work on Project. Could you create preliminary list of specific issues you would work on? That would make it a stronger proposal.
Difficult question
I see now why everyone has been asking me on IRC if I have any project* ideas for SoC. I think your assessment is pretty accurate. There's nothing I can think of right now that could really be worked on separate from the rest of the module. In the near future some things we'd like to get done are Views integration and the D6 port. I would hope that one or both of those are done before SoC would even start. Slightly more long term goals would be to finish integration of the project and project releases module with the Version Control API, and to create an upgrade path from the cvslog module to the VCS-CVS module. Also, there's been some push from the community to change handling of project issue subscriptions. I'm not sure how this is going to shake out--there are a couple of modules/frameworks (eg. Subscriptions module and notification framework) that are in development, but AFAIK neither of those could directly integrate with the project issues module without at least some glue code.
There's also the slight problem of mentor availability over the summer. I'm not sure how dww and hunmonk's schedules look, but I don't think I can commit to being a SoC mentor this summer.
With all of this being said, we'd love to get additional help with the project* modules, and as you pointed out they are very important modules for the Drupal community and development of d.o.
Do you have any ideas of your own? What in particular interests you? We might be able to come up with a good project that is helpful to the module but which isn't planned to be completed by the time SoC starts.
Mentors wanted?
I'd be available as backup mentor, especially for version control related tasks if those go into the application. Of course I'm biased with this, but there's considerable work that can (should) be done on the Version Control API still (as mentioned above by aclight, also see the eventual migration todo list as well as the Version Control API and CVS backend issue queues), and I'm willing to mentor my ass off except for all of July when I'm on a three-country trip and therefore not available at all.
The CCK conversion and issue subscription stuff would be worthy targets too, all three or even two of the mentioned issues (version control, CCK, subscriptions) would surely make for a sufficiently scoped SoC project imho.
Thank you for the offer!
Thank you for the offer!
I think it would be great if you could be my co-mentor. Especially in the beginning of the project you could help me to get into the Version Control code, since you'll probably know it by heart. =D
I think it would also be very handy to have you as a co-mentor, since we could maybe meet in Vienna some time...
Thanks for the feedback!
Thank you for the feedback. It's very important for me because I think that usefullness is the most important criteria for a successful SoC project.
Therefore I will probably propose a Version Control related project. I think that my efforts are put to a good use here.
There currently three open major issues with Version Control: this one, this one and that one.
Do you think these would be a good SoC project? Do you think that's feasable? How likely is it that they will be fixed before SoC actually starts?
Do you have any other ideas for a Version Control related project?
VCS is the way to go
I think that a VCS related proposal is a great idea, since we'd really like to get that moving so we can use it on d.o and it sounds like jpetso has some time for mentoring this summer.
I'm not sure that the three issues you listed themselves would make a good project, however. jpetso can give you more information than I can, but I was under the impression that those were rather short term goals and therefore might be finished before the summer.
If you haven't looked at http://groups.drupal.org/node/8102 already, that might help you get a sense of the road map for what needs to be done to actually use the VCS API on d.o.
There's also some info at http://groups.drupal.org/node/9002 as well.
Issues for Version Control API
The first one (the Great Database Schema Unification issue) is currently in the works and will (...must) be done before the SoC starts, so that you've got a solid base to start from and everything works again. Many of the changes in the API module itself are done already, and I'll make sure to do the rest in time.
The second one (altering the query from external modules such as the Project Node Integration module) is pretty easy given the work that has already gone into the first issue, maybe a day or two including the example usage in the Project Node Integration.
The third one (Drupal 6 port) might take a week at maximum, and while I appreciate help on that, it's not going to make for a full SoC project.
So if you plan to submit a Version-Control-only project, there needs to be more stuff in it. I'm sure we won't run out of work too soon, and there's a good number of tasks that I can think of:
I suggest you try to take on all of those, I think it suits the workload of a SoC project pretty well. In case there's unexpected difficulties, we can still drop the less important ones, but I'd say the tasks required for drupal.org and two of the other tasks should be feasible in any case.
Cross-posted to issue tracking group
Chad/Derek/Adam, any thoughts?
Here are some issues that I think are particularly interesting
Here are some issues that I think are particularly interesting:
I will look for some other issues and update this list.
What do you think about theese?
Comments
I think the views conversion is out of the question. That really should be finished by the time SoC starts (fingers crossed).
The project node UI redesign might be a good task, but the problem with this one is that everyone has a different idea of what the project nodes should look like, so you would really have to collaborate with a lot of community members. Kind of a design by committee problem. But, on the other hand, we really could use someone who was willing to take that on.
As for the matrix, I'm not exactly sure how useful that would be right now with the way the project download tables have been modified recently. Maybe someone should post a screenshot of a mockup in that issue to give an idea of what the desired outcome is.
if this can be scoped into a
if this can be scoped into a gsoc project and if the right mentor gets onto this - +1
http://www.twitter.com/lxbarth
CCK integration?
There's an issue here marked postponed: http://drupal.org/node/85049
So if views is done by the time GSoC starts, then what about that?
It's a big job.
It'll make the D6-D7 upgrade process easier.
It's relatively self contained in that it could happen in a 2.x branch.
It hopefully won't attract bikeshed/design by committee attention in the way that project node redesign might.
issue assignment
There are a few issues in the queue related to how issues are assigned to a user:
So, these seem like a good area to work since it is a commonly requested feature yet isn't blocked on any of the current work.
There's also that whole "metrics displayed in project node thing" we could see about reviving ;)
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
One other idea
Another idea for a SoC project that might work out well would be http://drupal.org/node/179471 (Make the project releases module use the core upload module instead of its own custom code). This would make it possible to attach multiple files to a release node. For example, one use case would be to have files packaged as both a .zip file and a .tar.gz file. Another (non d.o) would be to have, for example, a Macintosh and Windows version of some sort of compiled code available for download.
I think having files on d.o available as .zip and .tar.gz files would be a good idea, thought this has probably been the subject of discussions before. But after watching my wife, who is reasonably computer savvy, try to install Drupal this past weekend (on a Windows machine) and almost give up in the first step because she couldn't figure out what to do with a .tar.gz file, I think it would be nice to at least have the potential to do this on d.o. Other sites running the project releases module might find this even more useful.
I'm not sure that this task alone would be an entire SoC project, but I do think it's something that's unlikely to get done in the next several months. It would take some discussion with dww and hunmonk about how we want this to ultimately work.
Moving to "review complete"
The application has been posted to the Google web app, its scope has been adapted after some discussions, and it doesn't seem like a lot more comments will change the situation. Thus, moving to "community review complete".
Comments from hunmonk and dww would still be appreciated!
What is the proposal
I clicked on the link you posted but that takes me to a page where I have to register to be a mentor for SoC. Is the actual proposal for this available publicly? It's not clear to me what's being proposed.
OpenID integration as Identity Provider
Hi,
My proposal is to integrate OpenID as Identity Provider or basically OpenID server so that the user can login to any openid supported site using his own openid rather than a third party openid (such as wordpress or yahoo)
http://groups.drupal.org/node/10285
Wrong thread
This comment doesn't seem to have any relation to this discussion page, so wherever you wanted to post, I think you mixed up the threads and got the wrong one.
Not available publicly atm
The proposal, as indicated by previous comments in here, basically covers what I suggested in the above comment. I can't repost it verbatim though, adebar will need to do that by himself.
It'd be really handy if
It'd be really handy if adebar could repost the application to this thread so non-mentors can read it.
IMPROVING VERSION CONTROL API AND PREPARING IT FOR USAGE ON DRUP
IMPROVING VERSION CONTROL API AND PREPARING IT FOR USAGE ON DRUPAL.ORG
ABSTRACT:
The Version Control API together with it's backend modules decouples the Project module from a specific Revision Control System by providing a RCS-independent API. One of the major goals of this project is to make the Version Control API ready for actual usage on drupal.org. This will make it possible to use any of the supported RCSes on Drupal 6 and thus also on drupal.org. It is also planned to fix a couple of existing issues with Version Control and to implement some new features which will lead to increased flexibility and enhance the utility of Version Control.
The Version Control API, which originates from jpetso's last year's SoC project, has largely decoupled the Project module from cvs.module. This project will unleash the full pontential of the Version Control API and make it production ready for a new set of users including drupal.org.
IMPROVING VERSION CONTROL API AND PREPARING IT FOR USAGE ON DRUP
IMPROVING VERSION CONTROL API AND PREPARING IT FOR USAGE ON DRUPAL.ORG
Markus SCHANTA
IRC (freenode): adebar
1 - DRUPAL.ORG USERNAME:
adebar
2 - LINK TO PROPOSAL DISCUSSION:
http://groups.drupal.org/node/10068
3 - BENEFITS TO DRUPAL/OPEN SOURCE COMMUNITY:
After considering both previous SoC projects and present SoC proposals, I think it is worthwhile to work on a project that takes on some of the mid-sized issues, which are important, rather than spending a lot of time on a big issue which might be less significant.
Many of the sub goals of this project have been submitted by community members and/or are already listed on the issue queues of the respecting modules. Therefore I am confident that the solution of these problems is very valuable to the community.
3.1 One of the major goals of this project is to make the Version Control API ready for actual usage on drupal.org. When this is accomplished it will be possible to use a more modern revision control system (like Subversion which is frequently in the talks) on drupal.org.
3.2 The project will lead more flexibility in handling projects by removing some limiting assumptions (like the assumption that there can only be one account per repository or that it is sufficient to have one authentication method). This will open up a much larger user base than the status quo.
3.3 By merging efforts (replacing cvs.module and subversion.module with a Version Control API based solution, in accordance with the maintainers) future maintenance costs can be reduced.
3.4 As a part of this project it is also planned to fix existing issues with Version Control (see 4.4 for more details). It is also planned to introduce a number of new features (see 4.5, 4.6 and 4.7 for more details) which will lead to increased flexibility and enhance the usability of Version Control.
4 - PROJECT DETAILS:
The first step of this project will be to make the Version Control API ready for actual usage on drupal.org. This will require:
4.1 Porting all involved modules to Drupal 6 (Version Control API, Commit Log, Commit Restrictions, Account Status, CVS Backend, Project Node Integration and Subversion Backend; more details here: http://drupal.org/node/216375)
4.2 Adapting the release node integration which currently heavily depends on CVS. As this will require major refactoring of the project_release.module this can be considered as one of the most crucial tasks of this project.
4.3 Finish the script started by hunmonk to migrate existing cvs.module data to the various Version Control API tables.
4.4 Fixing a couple of smaller issues: (4.4.1) http://drupal.org/node/209402, (4.4.2) the implementation of get_directory_contents() (http://drupal.org/node/229350) and (4.4.3) the prevention of creating of branches through backdoor (http://drupal.org/node/207402).
Details about an eventual Version Control migration of drupal.org can also be found here: http://groups.drupal.org/node/8102
In case more tasks show up that are necessary for the drupal.org migration, those will also be fixed.
Once this is done, there's a couple of other tasks which will further improve the quality of the Version Control API:
4.5 Implementing subversion module's functionality in a Project and Version Control API based solution. The maintainer of the subversion module (halkeye) would like to cede this functionality to a Project and Version Control API based solution.
4.6 Make it possible to have multiple accounts per user and per repository. This will require changes in the Version Control API and the modules.
4.7 Create authentication method plugins to be more flexible with account authentication. This will make it possible to support multiple methods of authentication. Details: http://drupal.org/node/223891
5 - DELIVERABLES / PROJECT SCHEDULE:
The following tasks will have to be completed so that the project can be considered successful:
5.1 Port the modules listed under 4.1 to Drupal 6.0. Targeted for 2008-06-16.
5.2 Finish 4.2. Targeted for 2008-07-14. (As this is one of the most crucial parts of this project this will require a little more time.)
5.3 4.3 and 4.4. Targeted for 2008-07-28.
5.4 4.5, 4.6 and 4.7. Targeted for 2008-08-11.
jpetso (Jakob Petsovits) has already offered to co-mentor this project. This could be very benefiting since he is the main author of the Version Control API and he also studies in Vienna which makes it easy to meet up and would provide optimal mentoring quality.
To ensure the sustainability of my work I would like to contribute to the Version Control API and to the related modules once the SoC is over.
6 - BIO:
My name is Markus Schanta, I'm 21 years old and I live in Eisenstadt, Austria. Currently I study Software & Information Engineering at the Vienna University of Technology and Business Administration at Vienna University of Economics.
For several years I have been involved in a number of extracurricular activities such as my former schools student's council, Eisenstadt's local Linux User Group and most recently the Board of European Students of Technology.
For about two and a half years I've been working as a freelance web designer. I've been using Drupal for about one year and a half now, when a member of our Linux User Group first showed it to me. Ever since I used it for several sites (most recently http://wien.unimc.at, http://drsteinhofer.at, http://lsv-bgld.at, http://mangospa.at) and I was able to gather a good amount of experience on these assignments.
I've been working on a number of collaborative software projects (both for university and for extracurricular activities) and I know how the open source software processes work.
The application has been
The application has been submitted through the Google web app. You can see the most recent version above.
I can still change it until tomorrow. So if you think that there's anything that should be changed, please post in this thread.
Thanks to all the people who provided feedback for the proposal! Special Thanks go jpetso who has really been very helpful!
I think that's it for now. I can only hope that the reviewers will like my proposal! ;-)
Project accepted!
I'm so glad that my project was accepted right now!
Thank you all for providing feedback on my proposal!
I will post a link to my actual SoC08 wiki page as soon as I got one.
I really got the feeling that this will be a very exciting summer! =D